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ABSTRACT 

The purpose of this thesis is to evaluate the Staff Planning and Decision Support 
System (SPADS). The analysis presented uses the Modular Command and Control 
Evaluation Structure (MCES), a structured approach to evaluate C 2 systems using 
standard and evolving operational research tools. The analysis answered the 
following three problems by assessing the effectiveness of SPADS. Did SPADS 
provide the V Corps commander and his staff with the ability to exercise command 
and control of combat assets to meet overall mission objectives? Did SPADS 
demonstrate that the dispersed command post concept enhanced command 
survivability? Did SPADS evolve as a command and control force effectiveness 
system for the V Corps DCP based upon operational lessons learned? Appropriate 
measures of performance, effectiveness, and force effectiveness were identified to 
answer these problems. These measures and their assessment are presented as a 
strawman for consideration by the analytical community. As SPADS evolved from 
August 1981 to March 1985, it provided distinct advantages to the V Corps 
commander and his staff in terms of effective C 2 mission orientation, enhanced 
command survivability, and increased C 2 force effectiveness. 
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I. INTRODUCTION 



The purpose of this thesis is to present an analysis of the Staff Planning and Decision 
Support System (SPADS). This system was a Defense Nuclear Agency (DNA) 
exploratory development initiative in response to U.S. Army requirements for Command, 
Control and Communication (C 3 ) survivability of theater nuclear forces. The V Corps 
dispersed command post (DCP) concept was the basis for enhancing survivability. In its 
acquisition, SPADS represents an evolutionary development with each phase based upon 
the results of lessons learned during field exercises in central West Germany. 

The analysis presented uses the Modular Command and Control Evaluation Structure 
(MCES) to assess the effectiveness of SPADS. MCES is a structured approach to evaluate 
C 3 systems using standard and evolving operational research tools. Previous applications 
of MCES at the Naval Postgraduate School (NPS) have focused on theater-level and higher 
C 2 issues. A common characteristic of these analyses was the future focus on evaluating 
systems and testbeds. This is the first MCES-based evaluation of a tactical C 3 system that 
evolved from its conceptual stage to operational performance. 

A. MCES EVOLUTION 

The initial development of MCES grew out of a challenge to determine the force 
effectiveness of C 2 systems. A methodology was needed to describe C 2 systems 
architecture which would allow analysts to measure C 2 systems response and attribute the 
effectiveness of that response to the elements and/or structural relationships which form the 
C2 system [Ref. l:p. 13]. In 1984 Dr. Ricki Sweet and Lt. Col. Thomas Fagan III chaired 
a conference which focused on identifying issues and topics an analyst would address 
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when evaluating a C- system in terms of its contribution to force effectiveness. Five 
working groups were formed to address the following subjects: Definitions, Conceptual 
Models, the Identification of Measures of Effectiveness (MOEs), Evaluation Techniques 
and Approaches, and an overall appraisal of the current status and future course of MOE 
analysts [Ref. l:pp 24-27]. 

Subsequent workshops and conferences further defined expressed interests in and the 
need for further attention to C 2 systems. A "strawman" was developed by Drs. Morton 
Metersky, Michael Sovereign and Ricki Sweet to provide a framework for effectiveness 
analysts and deliberation at the 1985 Military Operations Research S< cL:y (MORS) 
sponsored workshop. This led to the publishing of an integrated document describing 
MCES in June 1986. 

MCES was designed to be applicable to any C 2 system, to be modified or altered to fit 
any C 2 system of interest. MCES methodology continues to evolve in order to resolve key 
C 2 issues. New C 2 tools and models have been identified, developed and integrated into 
MCES. 

Numerous efforts at NPS have been directed towards the application of MCES to 
various command and control issues. During the last two years, six master's of science 
degree theses have been completed using MCES at NPS. These theses spanned the range 
from applying MCES as a framework for acquistion management to analyzing the 
Identification Friend, Foe or Neutral (IFFN) Joint Testbed to evaluating C 2 components of 
the Strategic Defense Initiative (SDI) architecture. 

B . MCES METHODOLOGY 

MCES was developed during the 1980s as a structured approach to evaluate C 2 
systems and architectures. MCES defines "architecture" as a description of an integrated 
set of systems whose physical entities, structure, and functions are coherently related. This 
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representation of the architecture provides the ability to measure the C- system response 
and its effectiveness in directing forces to accomplish their mission. MCES uses standard 
and evolving operations research tools, and attempts to integrate previous, diverse efforts 
of decision makers and analysts to provide a concise C 2 evaluation structure [Ref. l:p. 13]. 

MCES is composed of seven sequential modules which guide an analyst through a 
comprehensive C 2 evaluation. Figure 1.1 presents the graphic structure of MCES 
methodology. 

The first module is used by both the analyst and the operational user to specify the 
particular C 2 problem. The next three modules employ the terminology and theory of 
MCES to describe the C 2 system architecture. This permits the analyst to model the C 2 
system and its operation. The methodology integrates the physical elements of the system 
with its process functions into a structural framework. In the fifth module, measures are 
identified, based upon the C 2 system bounding, which will be used to evaluate the C 2 
architecture. The sixth module requires appropriate data for measurement. The seventh 
module aggregates and evaluates the results for presentation to the decision maker [Ref. 
2:pp. 10-23]. (A more detailed explanation of how MCES is applied is provided in 
Appendix D.) 

C. SPADS BACKGROUND 

The U.S. Army V Corps, headquartered in Frankfurt, West Germany, attempted to 
employ a dispersed command post (DCP) configuration in the early 1980s. Despite early 
success with concepts and their employment, the corps was constrained by Army hardware 
and doctrine. Following several exercises that employed the early Target Acquisition and 
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Figure 1.1. Modular Command and Control Evaluation Structure 
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Planning (TAP) microcomputer workstations, V Corps requested assistance from DNA for 
the implementation of their DCP concept. In September 1981, DNA introduced the Staff 
Planning and Decision Support (SPADS) system at V Corps as the focus of its 
"Exploratory Development Program (EDP) in Support of TNF C 3 Survivability (Support 
of V Corps/8ID Dispersed Command Post)." DNA employed V Corps as the proof of 
concept experiment (POCE) testbed for SPADS from September 1981 through December 
1984. V Corps energetically used this evolutionary command and control system in every 
field training and command post exercise throughout the 1980s. 

The dispersed command post concept was the basis for enhancing survivability. V 
Corps Headquarters operated from dispersed cells, representing the traditional Corps 
Tactical Operations Center (CTOC), rather than from one large center that could present a 
lucrative target. The communications links between and among the dispersed cells were 
provided by the Army's Tactical Area Switching System (TASS). 

SPADS was a distributed information processing system that supported C 3 functions 
at multiple geographic locations. The system was designed for use in vans, tents, 
buildings, or armored command vehicles by functional staff personnel and commanders. 
The SPADS architecture consisted of a co-located group of staff duty stations linked by a 
local area network to form a module. Several modules were then interconnected by 
communication gateways through Army tactical communications to form a distributed, 
wide area network. The capabilities of the staff duty stations consisted of text editing, 
electronic mail, graphics and overlays, a relational database management system, map and 
photo correlation, spreadsheet models, and functional area algorithms. 

D. NATURE OF THE PROBLEM 

This thesis addresses the question: How effective was the SPADS system in the V 
Corps sector of the Central Army Group (CENTAG) region in: (1) providing decision 
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makers with the means to access and employ their combat assets to meet overall mission 
objectives; (2) demonstrating that the DCP concept enhanced command survivability; and 
(3) evolving as a command post support system, based upon operational lessons learned? 

To elaborate, this thesis will specifically attempt to assess SPADS' effectiveness in the 
following three problem areas: 

1 . Did SPADS provide the V Corps commander and his staff with the ability to exercise 
command and control of combat assets to meet overall mission objectives? 

2. Did SPADS demonstrate that the dispersed command post concept enhanced 
command survivability? 

3. Did SPADS evolve as a command and control force effectiveness system for the V 
Corps DCP based upon operational lessons learned? 

The resolution of the first problem requires a measure of effectiveness (MOFE) 
derived as a function of: (1) capability to achieve the C 3 system's objectives interpreted as a 
function of flexibility, availability, interoperability, and responsiveness; (2) structural 
components interpreted in terms of timeliness; and (3) the physical entities interpreted in 
terms of capacity. 

The second problem addresses command survivability as a function of dispersion, 
redundancy, and continuity of operations. And the third problem measures—across levels 
of operational capacity-the evolution of C 2 force effectiveness together with survivability. 
This final measure of command and control growth is thus derived as a function of the 
MOFE from Problem 1 and the MOE from Problem 2, with respect to time. 

Appropriate data for these three problems were gathered from after action reports, 
external evaluations, and operational experience. These data were generated during 
numerous field training and command post exercises from 1981 through 1985. A 
worksheet was developed to select specific data for the measures of performance, 
effectiveness, and force effectiveness. 
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As indicated in the preceeding paragraphs, several of the measures are functions of 
other, lower level measures. For the purpose of this thesis, the values are defined as the 
unweighted sum of the constituent measures of performance. Only replication and external 
validation can present more certainty on the assessment of factors and their aggregation. 
These measures and their assessment are presented as a strawman for consideration by the 
analytical community. 

E. THESIS ORGANIZATION 

This thesis summarizes how MCES methodology was specifically applied to evaluate 
the SPADS system. The doctrinal definition of a forward deployed, heavy corps is 
discussed in terms of MCES in Chapter II. Chapters III, IV and V present an MCES 
analysis of the three phases of the SPADS program. Finally, Chapter VI provides 
conclusions and recommendations concerning the SPADS program, evolutionary 
development, and the MCES methodology. 
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II. THE CORPS BASELINE 



A. PROBLEM DEFINITION 
1 . Background 

In the early 1980s, existing and projected Army communications systems 
inhibited rather than enabled command mobility. The standard small set of known, fixed 
command posts and communications nodes was vulnerable to disruption and destruction by 
Soviet radio electronic combat units. One solution to this vulnerability was to dramatically 
increase the number of C3 targets and mobility and to achieve position location uncertainty. 
There were other technical alternatives, but military application of these technologies 
resulted in prohibitive unit costs and frequent program curtailment or termination. Some 
means had to be found to substantially lower survivability costs. 

Potential solutions started to surface in military efforts to exploit the growing 
power of the microprocessor. The DNA, the Army's Training and Doctrine Command 
(TRADOC), and V Corps all initiated programs to achieve enhanced C2 survivability which 
were heavily dependent on new approaches to communications and command post decision 
aids. By 1981 V Corps began vigorously testing innovative command and staff procedures 
to support command post (CP) survivability, mobiiity, and effectiveness. The corps main 
CP used a closed-circuit TV system to support command and staff briefings in the 
consolidated Corps Tactical Operations Center (CTOC). Original plans to disperse the 
CTOC had been defeated due to an inability to transmit a secure video signal carrying text 
and graphic information. 

Meanwhile, TRADOC identified certain initiatives which the Army could pursue 
to enhance corps and division battle coordination efforts, including [Ref. 3:p 3-23]: 
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1 . Dedicating intelligence (Intel) and fire support element (FSE) personnel to work 
condnuously on analyzing data throughout the depth of the battlefield 

2. Placing a field artillery officer in the CTOC support (formerly the intelligence) 
element to process quick reaction, perishable, high priority targets directly to the 
appropriate attack means 

3. Dedicating a CTOC support element analyst to develop quick reaction priority targets 

4. Co-locating and training the G2/G3, FSE, tactical command post (TAC CP), and 
other staff elements designated by the commander to ensure synchronization of the 
deep, close-in, and rear battles 

5. Introducing the use of microcomputers in the FSE and CTOC support element to 
develop, analyze, and prioritize targets in a rapid and continuous manner 

6. Using closed-circuit TV and non-voice data links among critical staff elements 

During this same period, DNA fielded the experimental, microcomputer-based 
Target Acquisitions Planning (TAP) system in V Corps. The purpose of TAP was to 
develop, analyze, and prioritize artillery targets in a rapid and continuous manner. 1 The V 
Corps commander recognized a possible linkage between TAP and the efforts to disperse 
command posts. In May 1981, V Corps contacted DNA directly to request an expansion of 
the TAP program to support corps operations. First, V Corps requested that DNA provide 
personnel to conduct an in-depth analysis of corps requirements during the June 1981 
command post exercise. Second, the commander requested that an expansion of the TAP 
program, geared to the corps dispersed command post concept, be tested in September 
during REFORGER 81. [Ref. 4:pp. 1-2] 



!The TAP system employed microcomputer automation to provide an integrated 
capability for U.S. and NATO targeting staffs to identify Warsaw Pact echeloned forces in 
near real time. Intelligence and fire support staffs today employ TAP in conjunction with 
other automated systems to streamline the targeting process. It provides staff officers with 
an interim capability until such systems as All Source Analysis System (ASAS) and 
Advanced Field Artillery Tactical Data System (AFATDS) are fielded in the early 1990s. 
[Ref. 7:p. 27] 
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2 . Di spersed Command Post Concept 



The dispersed command post concept offers the possibility of reducing and/or 
disguising both the electronic and physical signatures of the consolidated CP. Nearly all of 
the communications and other electronic equipment, vehicles, and facilities found in the 
corps CP are also found in lower echelon CPs. If these assets could be reassembled as 
smaller modules and then dispersed on the battlefield, the enemy would find it very difficult 
to distinguish the main corps CP from many other, lower echelon CPs. In addition, once 
the CP is broken into smaller units, it is much easier to accommodate the components in 
civilian structures or small wooded areas. Supporting communications links could then be 
maintained at smaller regional nodes in a further effort to reduce the electronic signature. 

The traditional corps CP configuration in the early 1980s presented a target of 
some 150-meter radius. Either a small nuclear weapon or a well-targeted conventional 
attack could have destroyed nearly all of the C2 capabilities. Given the "kill radius" of even 
small nuclear weapons against CPs and other C3 facilities, DNA recommended a DCP 
system that called for the dispersion of the corps main CP— particularly the CTOC— into 
several modules that would be separated by a minimum distance of ten kilometers. DNA 
envisioned that this system would be extended throughout the corps CPs and eventually 
down to the division CPs. The corps CP would then be dispersed throughout an area 
approximately 40 kilometers by 50 kilometers. 

Despite expected difficulties in coordination, DNA concluded in 1981 that the 
DCP offered the greatest probability for the survivability of corps C2 on the modern 
battlefield. The conclusion reached by DNA was further reinforced by emerging U.S. 
Army doctrine revealed in TRADOC Pamphlet 525-5, The AirLand Battle and Corps 86 . 
dated 25 March 1981, which strongly encouraged the dispersion of critical C2 facilities. 
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To test this concept, DNA felt it necessary to establish a proof of concept testbed 
at an operational corps. In May 1981, the V Corps Commanding General sent an electronic 
message to DNA requesting assistance with a concept to employ microcomputers to 
support C2 operations in a dispersed command post. DNA took this opportunity to 
establish a testbed at V Corps with the objective of proving the DCP concept while 
developing an automated C2 system to enable its effective test and evaluation. 

3 . Evolutionary Acquisition 

Evolutionary Acquisition (EA) is not a cure-all for the real or perceived ills of the 
U.S. acquisition process; but it does hold promise to help field command and 
control (C2) systems sooner, at lower cost and with higher user satisfaction than 
other approaches. [Ref. 5:p. 23] 



The purpose of evolutionary acquisition is to be able to field critically needed 
operational capabilities (OCs) within six to 12 months, rather than the years that would be 
required under standard acquisition policies. Deployment of the initial operational 
capability (IOC) is accomplished during the first year. The operational users conduct 
studies and/or exercises in their own tactical environments with on-site technical assistance 
from the contractor. Command and control procedures — along with system capabilities — 
evolve and are tested and refined during each field test and exercise. 

Two critical components of this approach are incremental testing and user 
involvement. Hirsch noted that: 

A premise involved in using EA [Evolutionary Acquisition] to acquire C2 systems 
is that C2 systems are tested incrementally to determine whether the core system (or 
core system plus incremental upgrades to that system) meets the operational 
requirement. ...Therefore, users gain more extensive experience and make 
recommendations for establishment of operational requirements for subsequent 
system increments. This process of requirement evolution and introduction of 
upgrades distinguishes the evolutionary approach from the more classic weapon 
acquisition process. [Ref. 5:p. 26] 
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Each operational capability cycle is repeated to respond to changing 
requirements, to counter the new threat systems or techniques, and to take advantage of 
new and rapidly maturing technologies. Enhancements to the system are made within each 
cycle by adding or replacing components and by integrating new software that is tailored to 
specific military requirements. 

Subsequent operational capabilities consolidate incremental enhancements or 
involve complete system upgrades to take advantage of major advances in microcomputer 
technology. The result is a fully integrated system, tailored to meet the operational user's 
specific needs. The final operating capability remains undefined, due to the evolutionary 
nature of this developmental approach and the continued implementation of hardware 
and/or software modifications arising from user requirements. 

Operational capability cycles can be of different lengths or quantity. Milestones 
are normally sequential but can overlap. The initial responsibility of the operational user is 
to develop valid requirements. This requires an understanding of procedures which can be 
automated to meet the user's operational needs. Once the hardware configurations and 
software utilities are designed, the operational user has to identify and develop data 
structures and select those procedures to be automated. At the same time, the operational 
user plans manpower and training requirements for the evolving system. How the 
commander ranks these responsibilities strongly determines the initial success — or lack 
thereof — of early exercises and tests. 

4 . SPADS Evolutionary Development 

The SPADS evolutionary development approach arose from the evolutionary 
acquisition concept. This process was mandated by Department of Defense Instruction 
(DODI) 5000.2 (System Acquisition) which provided a method to rapidly refine an 
automated command and control system that employed state-of-the-art technology guided 
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by user requirements. DODI 5000.2 devised a new approach to counter the following 
impediments to rapid fielding of technological advances: 

1 . A ten-year lag between research and development (R&D) and effective system 
implementation, resulting in built-in obsolescence 

2. The ineffectiveness of systems that cannot respond to changing U.S. Army doctrine 

3 . The lack of affordability of automated systems that are tailored to user requirements 

SPADS evolutionary development produced its greatest benefits for V Corps 
when the operational users initiated a critical dialogue with DNA and the systems 
integrator. Hirsch noted that: 

In using EA [Evolutionary Acquisition] to acquire C2 systems, a major premise is 
that the real user— working in a close, continual relationship with the developer and 
supporter— should have a major voice in formulating operational requirements and 
defining detailed system characteristics. [Ref. 5:pp. 24-26] 

As a consequence of this approach, the resulting SPADS system was smaller, 
lighter, more rapidly deployable, and required less manpower to operate and maintain. 

5. Problem Focus 

The three problems identified in Chapter I will be examined under four 
conditions throughout the remainder of this thesis. The four conditions consist of the V 
Corps baseline and the three SPADS operational capabilities (detailed in Chapters III 
through V). Each condition will be evaluated using MCES, then the problems will be 
addressed at the conclusion of each evaluation. 

B . BOUNDING THE V CORPS SYSTEM 

In the terms of MCES, the V Corps C2 system consists of: (1) physical entities — the 
equipment, personnel and command posts; (2) structure — the hierarchical relationships, 
staff procedures, concepts of operation and information flow patterns; and (3) the C2 
process — what the command and control system was doing [Ref. 2:pp. 11-12]. (Appendix 
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E provides a detailed definition of the Army’s forward deployed corps in terms of mission, 
organization, operational concepts, threats to the corps, commander and staff, command 
posts, and communications support.) 

Emphasizing the battle management functions necessary to control a forward deployed 
corps in central West Germany, the V Corps C2 system could be defined structurally in 
terms of its hierarchical relationships, its geographical areas of responsibility within the 
Central Army Group (CENTAG), and the information flow patterns between command 
posts. Hierarchically, the corps received its commands from CENTAG; it had lateral 
relationships v/th the III (German) Korps to the north and the VII (U.S.) Corps to the 
south; it commanded the 3rd Armored Division (3 AD), the 8th Infantry Division (8ID), the 
11th Armored Cavalry Regiment (11ACR), the 12th Combat Aviation Group (12CAG), 
and numerous brigade-sized units. 

From a geographic perspective, V Corps was responsible for approximately 37,500 
square kilometers of real estate in the West German federal state of Hesse. 

Information flowed vertically and horizontally throughout the corps. The V Corps 
main and rear CPs received orders and information, and reported to the CENTAG CP; the 
corps support command received information from and reported to U.S. Army Europe 
(USAREUR) headquarters; the V Corps CPs transmitted orders and information, and 
received reports from the divisions, the armored cavalry regiment, and the major combat 
support and combat service support units in the corps area of operations. 

The V Corps headquarters was normally divided into three wartime command posts: 
the TAC CP, the main CP, and the rear CP. The TAC CP consisted of four armored 
command post vehicles, one platoon from the corps signal brigade, and necessary 
supporting vehicles. The TAC CP was 100 percent mobile and was capable of displacing 
every 12 to 24 hours. The main CP had very limited mobility and required considerable 



14 



time to displace. In addition, the main CP had prominent physical and electronic signatures 
that were very difficult to reduce. Like the main CP, the rear CP had limited mobility, 
many vehicles, and distinctive signatures. 

Prior to the implementation of the dispersed command post concept, the corps 
command posts were the main CP, the rear CP, and the TAC CP. The main CP consisted 
of Communications, Intelligence, Tactical Operations, and Air Support Operations elements 
compressed into a 300- by 300-meter area. The critical Tactical Operations Center (TOC) 
consisted of the Command, G1 (Personnel and Administration), G3 (Operations and 
Plans), G2 (Intelligence), Engineer, Weather, Fire Support, and Targeting elements in a 
75- by 75-meter area. During the same period, the division command posts were the main, 
rear, division TAC, and division rear CPs. 

Once V Corps decided to pursue the DCP, there was a concerted effort to realign 
physical entities and structural components. The main CP was restructured into four 
modules that supported four battle tasks. The new modules were CTOC, Plans, FSE, and 
Intel. The CTOC was similarly restructured; its new elements became Command, G3 
Operations (Opns), G2 Opns, G1 Opns, G4 Opns, Nuclear Biological Chemical (NBC), 
Engineer, and Corps Airspace Management Element (CAME) in addition to liaison officers 
from subordinated units, adjacent corps, and higher headquarters. 

C. ANALYSIS OF THE V CORPS C2 PROCESS 

To analyze the V Corps C2 process using MCES, it is necessary to specify the corps 
mission objectives, the commander's tasks, the staff functions, and the functions of each 
module in the three command posts. 

1 . Corps Mission Objectives 

The V Corps mission objectives can be defined in terms of four battle tasks: 
management of the current battle, planning the future battle, planning and executing the 
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deep attack, and sustainment of the force [Ref. 6:p. 2], The corps mission determines 
tasks to be performed and initiates the military decision making process, which proceeds in 
four phases: (1) collecting information; (2) planning— to include an estimate of the situation, 
a decision, and preparation of the operations plan; (3) issuing orders; and (4) supervising 
the execution of issued orders [Ref. 3:pp. 3-36 - 3-46]. 

2 . Corps Commander's Tasks 

In planning his battles, the corps commander analyzes his mission, defines 
tasks, establishes intelligence requirements and priorities, organizes the corps for combat, 
assigns missions and tasks to subordinate commanders, and sets priorities for combat, 
combat support, and combat service support units. In planning all operations, the corps 
commander must take into account available time and space required to defeat engaged 
enemy forces before divisions would have to fight follow-on forces. This becomes the 
"window" against which system performance must be assessed. As the plans are executed, 
the commander must be aggressive, demanding, and personally involved. The way the 
corps commander generates and applies combat power often decides the outcome of battles 
and campaigns. (Appendix E specifies the tasks performed by the commander in the 
forward deployed corps.) 

3. Corps Staff Tasks 

The commander requires assistance to assimilate information provided through 
the corps command and control system. He needs support to filter available information, 
demand more when the picture of the situation is not complete, analyze pertinent facts, and 
communicate decisions to the many people that must thoroughly understand his intent. The 
staff directs and coordinates execution of the commander's intent by providing the 
necessary control of the battle. Appendix C specifies those tasks completed by each staff 
section in the corps CP. [Ref. 7:p. 2-7] 
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4 . Command Post Functions 



The three wartime CPs of the V Corps Headquarters were identified in Section 
B. The orientation of the TAC CP is the most limited of the three command posts. With its 
focus on the close-in battle, the TAC CP monitors the deep and rear battles only for their 
impact on Forward Line of Own Troops (FLOT) operations. The main CP focuses on the 
deep battle. Although a major focus of the rear CP is to sustain operations in all three 
battles, it must also focus on fighting the rear battle. A major element of the rear CP is the 
rear area operations center (RAOC). The RAOC manages rear area protection, commands 
and controls rear area combat operations, provides current battle information to the rear CP, 
and acts as the alternate main CP. Appendix E presents the functions of each of the three V 
Corps command posts. 

Each module of the corps main CP is organized to support one of the battle tasks 
of the V Corps mission objective [Ref. 5:pp. B-l-1 -B-4-1]: 

1. The CTOC monitors the current situation in the corps sector and adjacent corps 
sectors. It allocates resources to major subordinated units in order to influence the 
current battle. The CTOC executes operations plans and operations orders. It 
ensures the availability of current battle information to all elements of the corps C2 
structure with emphasis on decision making information required by the commander. 

2. The FSE coordinates the attack of deep targets. The FSE also executes the attack of 
deep targets with air force support, organic missile artillery, and electronic warfare 
assets. 

3. The Plans module translates the commander's guidance into appropriate priorities for 
the intelligence effort, target development, the deep attack, and resource allocations. 
The Plans module also incorporates priorities and guidance into operations plans. 

4. The Intelligence module provides timely and reliable information on threat 
dispositions, capabilities, activities, and intentions. It tasks the intelligence 
collection assets to support operations plans. This module disseminates periodic 
intelligence reports to other modules, subordinate units, and higher headquarters. 
Finally, it nominates appropriate targets to the FSE. 
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D. V CORPS C2 SYSTEM ARCHITECTURE 

The V Corps C2 system architecture is described by an integrated set of systems 
whose elements and functions are coherently related. The corps physical entities and 
structural components (described in Section B) are mapped to the C2 process definition 
(Section C). Figure 2. 1 graphically represents this integration for the consolidated main 
command post. To construct the V Corps system architecture, it was necessary to map 
from the corps battle tasks— the highest level of this architecture— down to the module 
elements (or sub-elements) that perform the specific staff functions. (These functions are 
subdivided into specific tasks for each staff section or element in Appendix C.) First, the 
corps battle tasks were mapped to the corps CP functions. Next, the CP functions were 
decomposed into specific functions for each module. Then these specific functions were 
mapped to the module elements— or sub-elements— which perform them. Finally, the 
functions were mapped to the appropriate task of the particular element. Table 1 illustrates 
this mapping from one of the four corps battle tasks, "Manage the current battle," through 
one of the many CTOC functions, down to the specific tasks for each CTOC element, e.g., 
G3 Operations is tasked to "Monitor the current situation." 

After these architectural relationships were identified, the MCES provided guidance 
for both qualitative and quantitative measures based upon the specific form of data 
generation selected. 

E. SPECIFICATION OF MEASURES 

1 . Introduction 

The purpose of this section is to identify, develop, and select measures that gauge the 
V Corps C2 system's response to directing forces. These measures will provide the values 
used to assess performance and effectiveness by comparison-both at any point in time, and 
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as the underlying architecture of the C2 system changes from the V Corps baseline through 
the three operational capabilities. The measures are selected to relate directly to the 
architectural and operational issues posed in this analysis. It should be noted that additional 
measures might be useful for addressing another set of issues. 

Three problems were identified in Chapter I. The first asks whether SPADS 
supported the V Corps commander as he exercised command and control of his combat 
assets to meet the mission objectives in the four corps battle tasks. The second asks 
whether the V Corps dispersed command post concept actually enhanced command 
survivability. The final problem questions whether the SPADS evolutionary development 
approach affected C2 force effectiveness throughout the three OCs. 

2. Problem 1 

Four measures of performance (MOPs) and two measures of effectiveness 
(MOEs) were initially selected for the first problem. The MOPs were: (1) flexibility, (2) 
availability, (3) interoperability, and (4) responsiveness. These MOPs specified 
performance inside the C2 system using the criteria "yes-it-works/no-it-doesn't-work" 
[Ref. 2:p. 97]. The MOEs were: (1) timeliness and (2) capacity; these address structural 
components and physical entities respectively. A third MOE was developed as a function 
of flexibility, availability, interoperability, and responsiveness (FAIR) to address the C2 
process. Finally, a measure of force effectiveness (MOFE), addressing C2 mission 
orientation (^MOji), was defined as a function of the C2 process, structural components, 
and physical entities. Table 2 defines the measures selected for this problem. 
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3 . Problem 2 



In the second problem, the three MOPs selected were: (1) dispersion, (2) 
redundancy, and (3) continuity of operations [Ref. 6:pp. 1, B-l - B-2]. The issue of 
command survivability ( x CStD was addressed by defining an MOE that was a function of 
the three MOPs. The selected measures are defined in Table 3. 

4 . Problem 3 

The third problem was more challenging. SPADS could not evolve as a C2 
force effectiveness system based upon operational lessons learned unless it: (1) provided 
the commander, and his staff, with the ability to exercise command and control of his 
combat assets to meet overall mission objectives; and (2) demonstrated that the dispersed 
command post concept enhanced command survivability. Therefore, an MOFE related to 
C2 force effectiveness (C2/FE) was defined in terms of C2 mission orientation in command 
survivability. C2 force effectiveness is defined in Table 4. 

F. DATA GENERATION 

Appropriate data for the measures specified in Section E were generated from after 
action reports, external evaluations, and operational experience. Data were generated 
during numerous field training and command post exercises throughout the three OCs. 
These exercises closely followed the general defense plans used by V Corps to train for 
combat operations. In each exercise, the C2 system was exercised by highly trained staff 
officers and NCOs who used the system as they would in a wartime environment. 

The worksheet used to collect the data is shown in Table 5. This format was used for 
evaluating the three operational capabilities; the worksheet results are shown in Sections F 
and G of Chapters III, IV, and V. The corps baseline was evaluated using operational 
experience and doctrinal publications. After action reports were the principal source of data 
generation for the three operational capability cycles. 
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TABLE 4 

MEASURE SELECTED FOR THE THIRD PROBLEM 



Type Name/Formula Description 

MOFE C2 Force Effectiveness, = f (XMOTi, XCSTi) 

C2/FE, at Ti 

Command and control force effectiveness of the V Corps 
Dispersed Command Post can be interpreted, at the 
conclusion of an operational capability, as the summation 
of the values for command and control mission orientation, 
XMOTi, and command survivability, XCSTi. 



Each measure listed in Tables 1 through 3 was evaluated as a binary condition. The 
measure received a single, unweighted digit if it met the condition "the description of the 
measure in the table is true." Using the worksheet shown in Table 5, each module present 
during that exercise was evaluated for every measure. The results on the worksheet were 
columns consisting of ones and zeroes. Every summed measure (e.g.,FAIR, XMOTi, and 
XCSTi) received a cumulative, unweighted score on the worksheet. The Final measure, 
C2/FE, was computed using the description in Table 4, and the result was placed on the 
worksheet. The results of these evaluations are displayed in tables in Section F of Chapters 
ID, IV, and V. In addition, the means of each measure for the entire operational capability 
cycle are displayed in figures immediately following the tables. 

Two indicators of bias in the underlying data must be discussed. The first is missing 
data; in certain after action reports specific activities are absent and cannot be inferred. The 
second is observer unreliability; there are clear differences in both style and content 
between different writers of the after action reports. [Ref. 2:pp. 57-58] 
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TABLE 5 

DATA GENERATION WORKSHEET 



Baseline OC1 OC2 OC3 Exercise: 

Main CP TAC CP REAR CP 

CTOC PLANS FSE INTEL 

Problem 1: 

fair : ^ : > 2 j < j ; 

• Flexibility * J ' 1 | ! ) *2 * * ' 

• Availability 2 <2 j * J j J J 2 \ I 

• Interoperability ' J J 2 J « 2 < » ' > J 

• Linkability 1 1 < * * J 1 2 J 2 2 ■ 

•Usability ; I \ 2 I <2 ; « ; ; | 

• Responsiveness > ' > J * 2 ' 2 2 > 2 « 

• Hardware J 2 2 <2 < « ' > \ * J 

• Software * J ' J J 1 J 2 2 » 2 * 

2 ' ' ' 1 ! ' 1 ! 2 2 2 

TIMELINESS ; J ; 2 \ 2 \ <1 * . ; 

capacity ; ; : ; 2 ; ! : * ' \ 

xmoti ; ; ; 2 ; j 2 * * \\ ; 

Problem 2: J 2 2 j 2 ; ! ; j \\ \ 

DISPERSION ; 2 ; ; 2 ; j \ ; I J 1 

REDUNDANCY 2 ! I ' \ ' J 2 ; I 

• Key Info Elements J 2 J 1 2 » 2 * < ' « J 

• Skilled Personnel * j < | | J J I J 2 2 » 

continuity ; j ' ; ' ; • ; ; ; ; ! 

• Reliability \ >2 >2 j < J j J ; 2 

•Transportability » J • J J 2 1 >2 < < * 



XCSTi 
Problem 3: 
C2/FE 
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G . AGGREGATION AND INTERPRETATION OF MEASURES 

i . Gener al 

Problem 1 addresses command and control as a measure of force effectiveness 
derived as a linear function of the values for: 

1 . Mission orientation— the C2 process— which itself is interpreted as the summation of 
the values derived for flexibility, availability, interoperability, and responsiveness 
(FAIR) 

2. Structural components interpreted as a measure of timeliness 

3 . Physical entities as a function of capacity 

Problem 2 addresses survivability as a measure of effectiveness derived for 
dispersion and redundancy. 

In Problem 3, the measure of command and control force effectiveness is derived 
from the linear aggregation of the value derived for the MOFE from Problem 1 and the 
value of the MOE from Problem 2. The command and control force effectiveness of the V 
Corps CP was measured, at the conclusion of an operational capability, by adding the 
values derived for the evaluation of: (1) the interaction of mission orientation, structure, 
and physical entities in Problem 1; and (2) survivability in Problem 2. 

As indicated in Section E, several of the measures are functions of other, lower- 
level measures. The actual algorithm for any given application must be validated and 
verified against real world or other applicable observations. For the purpose of this thesis, 
the values of such proposed measures as FAIR, x MOji, x CSxi, and C2/FE are defined as 
the weighted sum of the constituent MOPs. However, other weights are arbitrary and the 
relationships could be linear or non-linear, relational or multiplicative. Only replication, 
conferencing and/or synthesis of expert opinion, and external validation can present more 
certainty on the assessment of factors and their aggregations. The major advantage of this 
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thesis is that it broaches the subject and presents a strawman for consideration by the 
analytical community. 2 

2 . V Corps Baseline 

In evaluating the V Corps baseline it would be counterproductive to attempt to 
apply the quantitative standards used for the three operational capabilities. The baseline 
condition requires a subjective evaluation based upon the appropriate doctrinal publications 
and operational experience. 

a. Problem 1 

Before implementing the DCP concept, the commander and his staff were 
able to exercise command and control to meet mission objectives. Certainly the staff was as 
flexible, available, and responsive as their procedures and communications support 
allowed. On the other hand, traditional command posts had no links to other C2 systems, 
and the staff received all of their information by hard copy message, facsimile or verbal 
report. Although staff members may have prided themselves on their efficiency, they had 
no way to speed up the flow of critical information from its source(s) to the commander. 
In a similar manner, the staff had only a limited capacity to handle data, reports, or 
functions during a given period; they were often overcome by events during operations. 

In analyzing the manual C2 process, it becomes obvious that technology would 
be hard pressed to meet the staffs contribution to the C2 functionality. However, the 
greatest potential of automated C2 systems lies in improving the physical entities' and 
structural components’ contributions to overall C2 mission orientation. 



2 Conversation between Dr. Ricki Sweet, Sweet Associates, Ltd, and the author in 
San Jose, California, 11 March 1988. 
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b. Problem 2 



The V Corps commander wanted to employ the DCP concept in 1981 to 
dramatically increase command survivability. (Appendix E describes the numerous threats 
to the corps command posts.) It was obvious at that time that merely dispersing the 
modules of the main CP would not be enough. A plan was required that would support 
continuity of operations with redundancy of functional staff personnel and key information. 
Before it implemented the DCP concept, V Corps had no way to consistently achieve 
command survivability. 

c. Problem 3 

The third problem cannot be fairly addressed with regards to V Corps' use 
of a consolidated main CP. Before dispersion, V Corps recognized the threats to command 
survivability and effectiveness but was constrained by Army doctrine and materiel in its 
efforts to improve the situation. 
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III. OPERATIONAL CAPABILITY 1 



A. PROBLEM DEFINITION 

The Defense Nuclear Agency started the first operational capability in September 1981 
with a microcomputer workstation demonstration during REFORGER 81. The exploratory 
development program had proceeded from concept formulation to the initial design and 
demonstration phase. Designs and capabilities were tested and refined during the four 
exercises of Operational Capability 1 (OC1): REFORGER 81, Able Archer 81, Crested 
Eagle 82, and Caravan Guard III. 

This section addresses four issues central to problem formulation: 

1 . What were the stated requirements of OC1? 

2. What tasks from the statement of work (SOW) supported OC1? 

3 . What design principles, mandated by DNA, guided the development? 

4. What were the goals of each exercise? 

Figure 3.1 shows the five requirements of OC1 along a month by month timeline 
consisting of 17 months. The dates of the four exercises during OC1 are marked by 
and are listed below the central rectangle. The objectives of OC1, based upon the re- 
quirements and the technological characteristics, are shown to the right. 

1 • Requirements for OC1 

OC1 objectives consisted of: (1) the effective implementation and operation of 
nine dispersed V Corps command post modules, (2) distributed processing through an 
automated communications gateway, (3) automated briefing files, (4) an electronic mail 
system, and (5) initiation of a divisional SPADS system. 
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Figure 3.1. Overview of Operational Capability 1 



a. V Corps DCP Concept 

The DCP experimentation program was conducted under Contract 
DNA001-81-C-0277 1 , awarded in August 1981. The purpose of the contract was to allow 
the earliest possible testing of the V Corps DCP concept. To accomplish rapid fielding, 
DNA employed non-developmental items (NDI) which took advantage of off-the-shelf 
technology. 

DNA established a testbed at V Corps; its objective was to develop an 
automated command and control system instrumental to testing and evaluating the dispersed 
command post concept. The primary test objective — evalua.ing the effectiveness of the 
DCP concept — would be accomplished while responding to the V Corps request of May 
1981 [Ref. 4:pp. 1-2]. What remained was to design an automated C2 system which could 
be fielded rapidly to support the test and evaluation of the DCP concept. 

DNA postulated a DCP model which called for the fragmentation of the 
corps main command post, particularly the Tactical Operations Center (TOC), into several 
modules and for dispersal of these modules with ten kilometers or more between them. 
DNA envisioned that the concept would be extended throughout the corps operational area 
to its supporting CPs such as the Rear Area Operations Center (RAOC) and the tactical 
command post (TAC CP), as well as to combat divisions and armored cavalry regiment. 
After action or lessons learned reports would be prepared for each exercise conducted 
during this operational capability period (August 1981 through December 1983). [Ref. 
8:pp. 9 -13] 



1 Interview between R. Laird, Lieutenant Colonel, USA, Defense Nuclear Agency, 
Alexandria, Virginia, and the author, 17-18 December 1987. 
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Since requirements were expected to be refined as the system was fielded 
and experimentation proceeded, an evolutionary development approach and modular design 
philosophy was adopted [Ref. 8:pp. 75-9]. This would allow early fielding of basic 
capabilities and subsequent DCP experiments, while providing the flexibility to add greater 
and more finely tuned capabilities throughout the test period. It would also allow the 
experiment to proceed without waiting for the availability of microcomputer and peripheral 
equipment based on emerging technologies, and it would maintain the ability to insert 
advanced capabilities when those technologies matured and new equipment was available in 
the commercial marketplace. 

b. Distributed Processing 

The V Corps automated prototype was required to support a distributed 
processing configuration consisting of a network of microcomputer workstations. (This 
definition contrasted with traditional automated systems composed of one central processor 
and dependent terminals that are incapable of independent processing.) A local area 
network (LAN) would connect workstations within each V Corps command post module. 
A communications gateway would provide network connectivity via Army voice 
communications channels. The supporting architecture would include a replicated data base 
at each module, thus providing each cell with the same information. The communications 
links between and among the modules were to be provided by the Tactical Area Switching 
System (TASS). The capabilities at each work station would eventually include word 
processing, electronic mail, graphics and overlays, a relational database management 
system, map and photo correlation, spreadsheet models, and functional area algorithms. 
[Ref. 8:pp. 36-38] 
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c. Automated Briefing 

An automated briefing capability was specified to enable any staff officer to 
create briefing slides and text at a workstation. In order to minimize communication 
requirements when transmitting these briefing slides to other modules, graphics 
information that was not expected to change would be created and stored as a background 
slide. Information that was expected to change would be created, stored, transmitted, and 
presented as an overlay. All slides would be stored on a module's mass storage station. 
New and updated slides from other modules were to be received through the 
communications gateway and stored at the mass storage station. A printing capability for 
text and graphics would be provided. [Ref. 8:p. 26] 

d. Electronic Mail 

An electronic mail system (EMS) was required to transmit messages 
between the workstations in the dispersed modules of the DCP. The EMS would be able to 
handle standard text messages as well as non-text material such as graphics. Mail would 
be prepared by the operator and would be sent to any other user through that module's 
gateway. [Ref. 8:p. 27] 

e. 8ID DCP Concept 

The 8th Infantry Division would be employed as a smaller and more tactical 
version of the V Corps testbed. The requirement was to provide dispersal plus 
effectiveness for the small, highly mobile elements of the division command posts. 

2 . Tasks from the Statement of Work 
a. Task 1: V Corps Support 

This task provided for support to V Corps during Exercises REFORGER 
81, Able Archer 81, and Crested Eagle 82. The first responsibility was to ensure that the 
current procedures, SOPs, reports, and information flow were examined before proceeding 
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with the project. The second responsibility was to gather specific requirements from the 
principal staff sections so that applications and data bases could be developed. 

b. Task 2: DCP Concepts 

The purpose of this task was to identify and test feasible information 
exchange concepts for the DCP project. For communications networking within the 
module, different commercial LANs would be tested and one selected to support SPADS. 
For communications networking between modules, gateway concepts would be examined 
and tested to determine the baseline for developing a communications gateway that could 
support the DCP concept. All networking tests would be conducted in CONUS. 

c. Task 3: Caravan Guard Support 

This task specified various tasks to support the V Corps DCP concept in 
Germany. The staff operators, NCOs, and action officers would be trained on how to use 
SPADS to support V Corps DCP operations. An SOP would be developed for dispersed 
operations that used microcomputer equipment. Communications gateway software 
development would proceed to support four dispersed CP locations. 

d. Task 4: PTT Management Interfaces/Procedures 

This task required that the West German national telecommunications 
system (the Deutsches Bundespost, or DBP) be examined to determine how it could 
support SPADS. The first test would determine whether gateways would be able to 
communicate over the standard DBP phone lines. This would be followed by tests to 
determine if special "conditioned" data links would be required to effectively use the DBP. 

e . Task 5: V Corps/8ID C2 Doctrine Evaluation 

This task would develop a capability to evaluate, through evolutionary 
testing, the effectiveness of the requirements for emerging Army doctrine on dispersed field 
C2. The principal effort would be to develop a testbed to evaluate an information 
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distribution and processing system between the corps, division, and corps/division 
command elements. The final test plan would provide a basis for documenting and 
evaluating the results of the theoretical efforts related to internal corps and division C2 
operations. 

Task 5 carried the V Corps DCP demonstration through the fall of 1982. In 
January 1982 the Army Communicative Technology Office (ACTO) provided $536,000 (of 
the $1.2 million required for SPADS up to that date) to purchase equipment for a "full-up" 
demonstration. 2 The pacing items would be software development and assimilation of the 
equipment by V Corps. 

f. Task 8: SID AirLand Battle DCP Program 

The purpose of this task was to develop a division-level SPADS program that 
would eventually be integrated into the V Corps DCP program. The sub-tasks were to: (1) 
deliver a division level SPADS system, (2) conduct user training for the 8ID, (3) support 
the user test of the system in garrison, and (4) support user tests of the SPADS system in 
the field environment. This task specifically required support for 8ID to develop and 
validate the operating procedures as well as to develop and test its own field procedures. 
The TRADOC Combined Arms Center contributed $480,000 in March 1982 to support the 
8ID SPADS development. 3 

3 . DNA Design Principles 

The DNA evaluated necessary automated command and control requirements 
from the perspective of battlefield information needs and the capabilities available from 
commercial NDI technology. That analysis produced seven design principles and an ap- 



2 Ibid. 

3 Ibid. 
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proach to evaluating the DCP concept. This section addresses those design principles that 
were incorporated in OC1. [Ref. 8:p. 16] 

a. Maintain a Common Battlefield Perception 

Every module in the DCP had to share a common perception of the 
battlefield situation if operations were to be effectively planned, executed, and controlled. 
This meant that every module must have the same information. A key design concept of 
the DCP automated C2 system was replication of the essential parts of the current situation 
information available at every module. Each module was responsible for maintaining a 
portion of the Current Situation data base and transmitting updates to all other modules. 
The common perception concept would [Ref. 8:pp. 17-18]: 

1 . Allow the commander immediate access to critical data on the total situation at any 
module and at any time 

2. Provide a common perception of all aspects of unit status to all corps modules 

3 . Provide redundancy necessary for continuity of operations 

4. Be less dependent on the communications system than remote query to a central data 
base 

5. Relieve the staff from the necessity of requesting critical information from other 
modules 

b. Minimize Data Transmission 

Limited Army tactical communications capabilities within the corps required 
a conservative data update philosophy to reduce the heavy burden that data, particularly 
data for graphics displays, could impose. The principle adopted for the DCP would be to 
transmit only overlay data through electrical means; backgrounds such as maps or chart 
matrices would be pre-positioned at all modules or delivered by courier. Only the data that 
changed (i.e., the overlays) would be sent through the communications network. [Ref. 
8:p. 19] 
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c. Maintain Continuity of Operations 

The critical requirement for continuity of operations influenced the DCP 
equipment configuration and recommended employment concept. The basic principle was 
to design for graceful degradation. If part of the system failed, the remaining components 
should continue to operate. Specific design features were [Ref. 8:p 21]: 

1 . Distributed, intelligent workstations would be selected rather than the traditional, less 
capable terminals serviced by a multi-user central computer 

2. A graphics plotter would be employed at selected modules to periodically provide 
backup acetate overlays of the force status and enemy situation; this duplication 
would ensure that critical map overlays would be available even if the system totally 
failed 

3. A medium-speed printer would provide hard copy text and ensure that essential 
records were kept in the event of a major system failure 

4. A direct communications interface between selected workstations at distant modules 
would provide backup communications in the event of a gateway failure or during 
peak traffic backlogs 

5 . The data bases and current situation briefings would be duplicated at each module; 
each module would contain the data necessary to reconstitute the functions of a 
destroyed module 

d. Computational Support 

Each module would have its own set of requirements for analysis, e.g., 
generating spreadsheets on personnel and equipment needs, or for creating local data bases. 
The system would be designed to provide the capability of executing commercial software 
programs and creating local programs to meet the needs of each module. This principle 
would ensure maximum utilization of existing programs and enable individual staff 
elements to develop software tailored to their specific needs. [Ref. 8:p. 21] 

e. Provide a Rugged, Low-cost System 

The DCP program was required to use commercial equipment modified for 
field use. The time to develop and field the system was thus expected to be one-fifth of the 
normal development time because of the use of off-the-shelf commercial products. This 
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would also maintain a lower cost than conventionally developed hardware and software 
programs. 

It would be necessary to take some steps, without attempting full 
militarization, to ensure that the hardware package would perform effectively in the field. 
The microcomputers would be modified to provide simple connections between the 
computer and other devices in the system. This would alleviate the need for an operator to 
open the microcomputer case to make connections in the field environment. Special 
transport cases would be designed to protect the equipment from exposure and during 
transportation. The rigid cases would provide the structural framework for the operating 
workstations. [Ref. 8:p. 21] 

4 . Exercise Objectives During PCI 

The objective for Exercise REFORGER 81 was to demonstrate the 
capabilities of a microcomputer workstation in the corps main command post. The 
objective of the next exercise. Able Archer 81, was to demonstrate that files could be 
transferred over Army tactical communications between microcomputer workstations in 
different modules. The two objectives for Exercise Crested Eagle 82 were to: (1) conduct a 
test that demonstrated that bulk-encrypted data could be transferred between two modules 
using TASS, and (2) to add the 8ID to the DCP experiment. The five objectives of the last 
exercise, Caravan Guard III — the most significant of OC1 — were to: (1) simulate the 
dispersal of nine modules, (2) use the automated communications gateway station (CGS) 
over TASS, (3) connect the 8ID main CP to the corps SPADS system, (4) disperse the 
TAC CP up to 45 kilometers from the main CP, and (5) implement the Current Situation 
and Electronic Mail System (EMS) software. Table 6 presents the exercises and objectives 
ofOCl. [Ref. 8:pp. 26-28] 
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TABLE 6 

OVERVIEW OF OPERATIONAL CAPABILITY 1 

Primary Objective(s) Date 



Contract Award 


Aug. 


1981 


Exercise REFORGER 8 1 


Sept . 


1981 


Demonstrate microcomputer workstation 


Exercise Able Archer 81 


Jan. 


1982 


Demonstrate file transfer 


Exercise Crested Eagle 82 


March 


1982 


Transfer bulk-encrypted data between two modules 




Exercise Caravan Guard m 


June 


1982 



Disperse nine CP modules 

Automate communications gateway over TASS 

Add 8th Infantry Division to experiment 

Disperse CP modules up to 45 km apart 

Test Current Situation and Electronic Mail System 

B . BOUNDING THE C2 SYSTEM 

This section addresses the bounds of the SPADS system in terms of physical entities 
and structure at three distinct levels. First, the workstation bounds the hardware and 
software with which an operator interacts. Next, the module level describes the SPADS 
entities and structure within the confines of one modular command post. Finally, the 
network level defines the SPADS system within the geographical and hierarchical bounds 
that interconnect the modules. 

1 . Workstation Level Bounding 
a. Hardware 

The only hardware that the staff officer or SPADS operator interacted with 
personally was the staff duty station (SDS). The SDS was contained in two ruggedized 
cases that stacked one atop another to provide an operational workstation. The upper case 
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contained two monitors. The lower case contained an Apple 4 11+ microcomputer, two 
floppy diskette drives, and a power control panel. The Apple 11+ microcomputer was the 
central focus of the SDS. Inside the microcomputer case were numerous interface cards to 
control the disk drives, provide accurate time, interface with the printer, provide a serial 
port for a modem, and provide extra random access memory (RAM). The operator typed 
all commands at the keyboard. Two 5-1/4-inch floppy diskette drives were attached to the 
backplane of the microcomputer. These drives could be used to store and input data or to 
execute commercial software programs. On the left side of the upper SDS case a black and 
green (B&G) monitor provided for text display. To the right, an analog color monitor 
displayed briefing slides. Table 7 presents an overview of the SDS hardware. [Ref. 8:pp. 
38-41] 

b. Software 

All SPADS software functions were performed at the SDS by the operator. 
The two required functions implemented during OC1 were Current Situation and Electronic 
Mail System (EMS). Current Situation provided an immediate overview of the battle 
situation, including the status of units. It was dependent upon the Briefing package, which 
provided the ability to create and present briefings. EMS allowed the operator to send or 
receive standard text messages, data, graphics, and computer code. One flexible SPADS 
software package was Local Program Execution, which allowed the operator to execute 
programs locally, e.g., special programs to assess personnel needs, logistics support, and 
other staff tasks. [Ref. 8:pp. 44, 48] 



4 Apple is a registered trademark of Apple Computer, Inc., Cupertino, California. 
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TABLE 7 

STAFF DUTY STATION HARDWARE 



Microcomputer 


Apple n+ 


Processor 


Synertek MOS 6502, 8-bit data 


Memory 


48K (64K with Slot 0 Card) 


Graphics 


5x7 Dot matrix for 280 x 192 array 


Monitors 


Analog Color Display 
Black and Green Display 


Keyboard 


52-key typewriter keyboard (attached) 


8 Slot Expandable Bus 




Power supply 


120V/50-60 Hz power 


Floppy Drive (2) 


5-1/4-inch, 140 Kbytes 



The Current Situation package preceded any common data base function in 
SPADS. Current Situation allowed text and slide displays of any data that the staff wished 
to include. Current Situation data consisted of input from local users plus information 
obtained from staff sections in other modules. All information generated or received was 
stored on the module's mass storage station. All locally generated slides and text used in 
Current Situation were transmitted through the CGS to the other command post modules. 
Any operator was able to obtain a hard copy printout of the text and graphics information 
from the shared output station. [Ref. 8:p. 48] 

The operator was able to create briefing slides and text at the SDS. In order 
to minimize communications requirements when transmitting slides to other modules, 
graphics information that was not expected to change from one slide to another was created 
as a background slide. Information that was expected to change was presented as an 
overlay. When updates were needed to a given set of slides, only the overlays had to be 
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transmitted. The text provided with the slides described the essential features of the 
displayed graphics information. [Ref. 8:p. 56J 

EMS was the principal mechanism for transmitting messages between the 
modules of the DCP. EMS handled all standard text messages as well as non-text material 
such as graphics. Outgoing mail was prepared at the SDS by the operator. Incoming and 
outgoing mail was handled by the gateway. All mail was stored in "mailboxes" on the hard 
disk of the mass storage station. The mail could be called up for reading by addressees, 
sent to the shared output station for printing, or both. [Ref. 8:p. 51] 

2 . Module Level Bounding 

A SPADS module consisted of one or more staff duty stations, a mass storage 
station, a shared output station, and a communications gateway station, all interconnected 
by a local area network. Table 8 presents a summary of the module-level hardware and 
communications capabilities. 

The mass storage station (MSS) was the primary shared memory for the SPADS 
module. It normally contained all of the data, text, graphics, and computer programs for 
each module. The MSS consisted of a hard disk drive, a hard disk server, and a 
videocassette recorder (VCR). The server controlled access to the hard disk and its 
operations. These included local work files used by each SDS as well as common data 
base files. The VCR was used to create a backup copy of the hard disk. Only one MSS 
was installed at each module. 

The shared output station (SOS) provided medium-speed, medium-volume 
printing and plotting capability to support the module's SDS operators. An SOS consisted 
of an SDS, a printer,and an optional plotter. Some modules had a plotter capable of 
producing large map overlays, hard copy slides, and conventional hard copy paper plots. 
All the SDSs in a module had access to the SOS for their printing and plotting needs. The 
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SOS was essential for nodule operations during OC1 because the SDSs did not have local 
printers available. [Ref. 8:p. 44] 



TABLE 8 

MODULE-LEVEL HARDWARE AND 
COMMUNICATIONS CAPABILITIES 



Gateway Microcomputer: 

• Apple H+ (four required/gateway) 

- Synertek MOS 6502 

- 48K (Expanded to 128K) 

- 5 X 7 Dot matrix for 
280 x 192 array 

- 120V/50-60 Hz power 
Corvus a 20 Megabyte Hard Disk: 

• Winchester technology 

• 64 device capable common bus 

• 1000 foot trunk length 

• Non-collision network 



Communication Hardware: 

« Multichannel — TRC 151/145 

- Bulk encryption — KG-27 

- 300—1200 baud 

• TASS switching — TTC 38/41 

« PTT-KG-84: 300— 1200 baud 
Software Capabilities: 

« Variable packet size 

• RS 232/RS 422 protocols 

• Error detection code 

• Corvus Constellation protocol 



The communications gateway station (CGS) was the link between each SPADS 
module and all the other cells in the DCP. It was mandatory for module operation. The 
CGS consisted of three Apple 11+ microcomputers, up to four modems, and two B&G 
monitors. Its purpose was to process incoming information, control the transmission of 



a Corvus is a registered trademark of Corvus Computers, San Jose, California. 
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outgoing information and maintain the EMS network control. Figure 3.2 presents a 
schematic of the Apple 11+ Communications Gateway Station. [Ref. 8:p. 44] 

3 . Network Level Bounding 

The DCP consisted of a network of SPADS modules with one gateway per corps 
command post module. In the initial distributed command and control network, the CGSs 
were connected via the Army Tactical Area Switching System over tactical multichannel 
radios or cable systems. [Ref. 8:pp. 28-30] 

C. C2 SYSTEM ARCHITECTURE 
I . Workstation Level Integration 

Once V Corps had working staff duty stations in its modules, the staff began to 
implement manual functions either through provided SPADS software or through local 
program execution. Chapter II presented an overview of the functions of the corps 
commander and staff in any CP configuration. (Appendix E provides an in-depth look at 
the tasks that must be performed by the corps staff.) Even before SPADS was being 
formalized in procedures and SOPs, resourceful staff personnel were using SPADS to per- 
form more effectively. 

The next four figures present the integration of each software package with the 
C2 system and the C2 process. First, Figure 3.3 displays the integration of system, 
process, and function with Current Situation [Ref. 8:pp. 48-49], then Figure 3.4 shows 
the integration of entities, structure, and functions with Briefing [Ref. 8:pp. 56-57]. Next, 
Figure 3.5 illustrates the integration of Electronic Mail System with the processes, 
structures and entities [Ref. 8:pp. 51-52]. Finally, Figure 3.6 depicts the integration of 
system elements and functions with Local Program Execution [Ref. 8:pp. 44, 48, 62]. 
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Figure 3.2. Schematic of Apple 11+ Communications Gateway 
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Figure 3.3. Integration of the Current Situation 
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Figure 3.4. Integration of the Briefing 
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Figure 3.5. Integration of Electronic Mail System 
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Figure 3.6. Integration of Local Program Execution 



2 . Module Level Integration 



Throughout OC1 the addition of SPADS hardware and software was slowly 
influencing the structure, organization, procedures, and information flow patterns of the V 
Corps command posts. In comparison to Chapter II’s pre-DCP architecture, Figure 3.7 
presents module-level integration within a generic module during OC1. 

3 . Network Level Architecture 

The most significant integration at the network level in OC1 occurred during the 
period that covered Crested Eagle 82 and Caravan Guard III. In March, during Exercise 
Crested Eagle 82, two corps modules were physically dispersed and transmitted files 
between them. Furthermore, during Exercise Caravan Guard III in June 1982, nine 
modules of the V Corps DCP concept were used and SPADS links were established 
between four dispersed modules. In addition, the 8ID main CP was connected to the V 
Corps main CP through SPADS at a distance of almost 40 kilometers. 

Once the corps was able to support the DCP concept through SPADS 
communications gateway stations, it was in a position to begin integration of the V Corps 
C2 process from the individual staff duty stations throughout the entire network. 

D. DATA GENERATION 

The data generated for this OC are shown in Table 9 5 . The data generation worksheet 
and formulas discussed in Chapter II were used to produce values for this OC. The means 
for each evaluation category are displayed in Figure 3.8. A brief review of the data 
generation procedures — presented in Chapter II — follows in the next paragraph. 



5 The following sources provided raw data on these exercises: Reference 
(REFORGER 81, Able Archer 81, Crested Eagle 82, Caravan Guard III), Reference 10 
(Caravan Guard III), Reference 11 (Caravan Guard III), and Reference 12 (Caravan Guard 
III). 
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Figure 3.7. Integration at the Module Level in Operational Capability 1 
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Figure 3.8. Means for Each Category During OC1 



After action and lessons learned reports were collected from V Corps, DNA, and the 
developer for each exercise during this operational capability cycle. Using the worksheet, 
definitions, and procedures specified in Chapter II, values were determined for each 
measure from every exercise. The measures were individually considered as binary 
conditions for each DCP module that participated in the exercise. The summed measures 
(e.g., FAIR, XMOTi, and XCSTi) received their cumulative, unweighted scores based 
upon their constituent measures of performance or effectiveness. The final measure, 
C2/FE, was computed as a linear function of XMOTi and XCSTi and recorded on the 
worksheet. The results for each exercise are displayed in Table 9, and the means for each 
category are presented in Figure 3.8. 

The reader should exercise caution in interpreting the values generated for OC1. The 
scarcity of data and the biases noted in Chapter II lead to a necessarily conservative view of 
the accomplishments of the V Corps DCP program during this 17-month period. 

E. AGGREGATION AND INTERPRETATION OF MEASURES 
1 . C2 Mission Orientation 

The value of C2 mission orientation, XMOTi, rises dramatically during OC1. 
This may be a gain in effectiveness; however, it may also represent the natural reaction to 
coping with the dispersed command post environment. The following subsections interpret 
the three components of C2 Mission Orientation, 
a. C2 Process 

There was a dramatic loss in functionality during OC1, and SPADS could 
have been exploited to regain the level of functionality that existed before dispersal [Ref. 12: 
pp 21-22]. While the functions of the V Corps commander and staff remained constant, 
the environment they had to work in changed drastically. The rise in FAIR represents the 
increasing functionality of the SPADS system within the DCP environment. 
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b. Physical Entities 

The physical entities of the V Corps C2 system changed the most during 
this period. As the facilities were dispersed, new hardware and software was introduced to 
increase command survivability and bring C2 mission orientation up to its pre-dispersal 
level. The value of capacity remained constant for each module that was added to the DCP, 
but the total aggregated value increased as the modules were networked by the gateway and 
through TASS to one another. 

c . Structural Components 

The value of the structural measure remained at zero thiout,hout OC1. 
SPADS was not able to accomplish the transmission of critical information required by the 
commander during this period. During each exercise more traffic was generated than in 
previous ones, but at no time could the V Corps commander depend on SPADS for critical 
decision making information. 

2. Command JSiimbailjLliLy 

SPADS was able to make significant gains towards achieving command 
survivability during OC1. Dispersion between modules gradually increased from zero up 
to 48 kilometers — well beyond the minimum ten kilometers required. On the other hand, 
no progress at all was made toward redundancy; this specifically related to command 
influence and staff interest. Previous Army C2 systems and research studies indicated that 
if the commander did not provide personal leadership and demand use of the system, then 
the staff members would only use it in a haphazard manner. [Ref. 13:pp. 2-8 - 2-1 1, 2-39 
- 2-42] Finally, the values of reliability remain constant throughout OC1, while the value 
for transportability rises to a steady level by Exercise Caravan Guard III. 
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3 . C2 Force Effectiveness 



SPADS clearly evolved during OC1 based upon the operational lessons learned. 
However, it is not clear that it evolved as a C2 force effectiveness system during this 
17-month period. The evolution involved hardware, software, protocols, and 
communications interfaces. SPADS had not affected the organization, procedures, or 
concept of operations for the V Corps command posts. The dramatic rise in the value of 
C2/FE is directly related to the increase of XMOTi during the period; more specifically, it is 
related to the values of FAIR which measure the interactions of the C2 process. The 
measure of the structural component remains zero throughout OC1; therefore, it must be 
stated that C2/FE does not "evolve" during this period. 

Figure 3.9 provides the cumulative (unweighted) value of each evaluation 
category for each exercise of OC1. Figure 3.10 displays the increasing value of each 
measure — XMOTi, XCSTi, C2/FE — throughout each exercise of the first operational 
capability. 

F. SUMMARY 

A basic workstation concept was demonstrated in Exercise REFORGER 81 during the 
month following contract award. By Exercise Crested Eagle 82, the SPADS concept was 
being verified with two modules passing data over encrypted TASS circuits. The 
experiment was accelerated with the deployment of nine modules in Exercise Caravan 
Guard III in June 1982. The V Corps rear, RAOC, and TAC CP modules were dispersed 
some 19 to 45 kilometers from the main CP and a connection was made to the 8ID main CP 
SPADS system at a distance of 48 kilometers. The main CP itself was broken up into five 
modules with dispersion simulated by distances of 100 to 400 meters between modules. 
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Figure 3.9. Evaluations of the Three Problems for OC1 
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Figure 3.10. Comparisons of the Three Measures for OC1 



The rapid deployment of equipment, the limited training time allocated to the staff and 
operators, and the lack of command influence and staff interest resulted in a mediocre 
demonstration of the SPADS system's ability to effectively support a dispersed command 
post. Nor was SPADS able to obviously enhance the commander's ability to achieve 
mission objectives during this period. However, the DCP concept had shown that it could 
be technically viable if SPADS equipment, software, procedures, and interface could be 
improved during the next OC. The key to success for SPADS would have been the direct 
influence of the commander, and the role the staff took in integrating SPADS into the entire 
V Corps C2 system [Ref. 13:pp. 2-39 - 2-42], 
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IV. OPERATIONAL CAPABILITY 2 



A. PROBLEM DEFINITION 

The second operational capability (OC2) began Field testing in September during 
REFORGER 82. OC2 was planned and designed to use OC1 as a baseline condition and 
progress from there. Once again, designs and capabilities were tested and refined during 
the operational capability’s four exercises: REFORGER 82, Able Archer 82, Wintex 83, 
and Caravan Guard IV. 

This section addresses four issues central to problem formulation: 

1 . What were the stated requirements of OC2? 

2. What tasks from the statement of work (SOW) supported OC2? 

3. What other design principles, mandated by DNA, guided the development? 

4. What were the goals of each exercise? 

Figure 4.1 shows the seven requirements of OC2 along a month by month timeline. 
The dates of the four exercises during OC2 are marked by and are listed below the 
central rectangle. The objectives of OC2, based upon requirements and technological 
characteristics, are shown to the right. 

1 . Requirements for OC2 

The seven OC2 objectives to be completed during the 19-month period were: (1) 
development of videodisc-generated maps and overlays, (2) distributed and replicated data 
bases, (3) minimized data transmission with automated reporting capabilities, (4) 
development of a 16-bit microprocessor communications gateway station, (5) dispersal and 
effective operation of 13 modules in the V Corps DCP concept, (6) full implementation of 
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Figure 4.1. Overview of Operational Capability 2 



the 8ID DCP concept, and (7) fielding of an improved Apple communications gateway 
station. 

a. Videodisc-generated Maps and Overlays 

OC2 specified videodisc-generated map and overlay capabilities that used 
standard map images and overlays of military symbols or icons. The maps were to be 
stored on videodisc. To minimize data transmission, only overlay images were to be sent 
electronically. [Ref. 8:pp. 32-33] 

b. Distributed and Replicated Data Bases 

The DBMS was to provide the basic capability for an operator to extract 
information from the data base and to enter new or update information. The SPADS 
DBMS was to provide the staff with a flexible, responsive and powerful data base. Two 
data bases were scheduled to be delivered at the beginning of OC2: the Battlefield 
Information Reporting System (BIRS), and the Order of Battle (OB). The BIRS data base 
was to be constructed to store friendly force data; the OB data base would provide storage 
for enemy force information. These were to be replicated data bases that would be updated 
throughout the SPADS network, and all SDSs would be able to obtain the same current 
information from their local module's hard disk. [Ref. 8:pp. 32-33] 

c. Minimized Data Transmission with Automated Reporting 

Capabilities 

Automated reporting capabilities were to be designed so that only data (and 
not the report format) would be transmitted electronically. This requirement was similar to 
the capability achieved in OC1 where only graphics overlays were transmitted. [Ref. 8:p. 
32] 
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d. 16-bit Microprocessor Communications Gateway Station 

Development 

This requirement marked a technological enhancement in the gateway 
function. The CGSs were taxed to their limits during full-up tests of the DCP. Therefore, 
a newer generation microcomputer with 16- and 32-bit architecture was to be selected to 
increase the speed of message traffic transmission and reception. [Ref. 8:p. 33] 

e . Dispersal and Effective Operation of 13 Modules in the 

V Corps DCP Concept 

The DCP experimentation program was to continue until the entire V Corps 
command post structure could be fully dispersed while effectively performing all corps 
battle tasks. This phase of the program was to progress from the accomplishments of 
OC1. Full dispersal would be conducted in parallel with the refinement of SPADS system 
requirements and the technological enhancements necessary to meet all of the OC's 
objectives. 

After action or lessons learned reports would be prepared for each exercise 
conducted during the time period of this operational capability (June 1982 through 
December 1983). [Ref. 8:pp. 28-31] 

f. Full Implementation of 8ID DCP Concept 

During OC1 the 8ID made progress toward employing a DCP concept. 
During OC2 further resources were to be dedicated to developing a more rugged, 
transportable and survivable version of the SPADS dispersed command post environment. 
[Ref. 8:p. 33] 

g . Improved Apple Communications Gateway Station 

Selecting a more powerful CGS (Requirement d.) was a long-term solution 
to the gateway problem. A short-term fix was required to support the 8ID DCP concept 
and to provide a smaller, more capable CGS for all modules. [Ref. 8:p. 33] 
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2 . Tasks from the Statement of Work 



a. Task 7: Support for REFORGER and Able Archer 

This task provided for "on-site" contractor support at V Corps for 120 days. 
It would support a limited SPADS demonstration during REFORGER 82 and fund a test of 
the full-up DCP concept during Able Archer 82. It was to provide assistance to V Corps to 
develop SOPs for each functional area of the staff. Finally, it would provide for 
corrections and refinements to the software developed under Task 3 in OCl. 

b . Task 8: 8ID AirLand Battle CP Program 

Sub-task 8e would continue 8ID support through REFORGER 82. 

c. Task 9: Baseline Support 

This task provided for support during REFORGER 82, Able Archer 82, 
Wintex 83, and Caravan Guard IV. This support was to increase the overall effectiveness 
of the system, increase user friendliness and improve clarity. 

d. Task 10: On-site Support through Wintex 83 

This task required that the developer coordinate with the V Corps staff to 
clarify staff requirements for SPADS development. 

e. Task 11: 16-bit Microprocessor Communications Gateway 

Station 

Task 1 1 began the gateway software conversion from the Apple II 8-bit 
code to the Corvus Concept 16- and 32-bit code. 

f. Task 12: SPADS System Training Documentation 

Task 12 required that written and audiovisual instructional materials be 
developed. The written materials would include: (1) a User's Guide to the software 
capabilities, (2) a Technical User's Guide to assist system managers in operating the 
gateways and gaining a deeper understanding of module operations, and (3) a Concept of 
Operations Manual aimed at educating staff officers about SPADS. 
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g. Task 13: DCP Videodisc Support 

This task was not specified. 

h. Task 14: Support to Exercise Caravan Guard IV 

The final task for 0C2 provided for support for pre-exercise training, 
equipment upgrades, and exercise support for Caravan Guard IV. The equipment upgrades 
would include the new ACTO mini-SDS for the CBC and Intel modules as well as an 
upgrade for the Apple CGS. The Army Training Support Center, Fort Eustis, VA, 
provided $770,000 in March 1982 to purchase microcomputers, videodisc players, hard 
disk drives and computer networking equipment to support Caravan G ar.' IV. This was a 
joint effort of V Corps, ACTO, DNA, FORSCOM and TRADOC's Combined Arms 
Training Development Activity. 1 

3 . DNA Design Principles 

The second operational capability continued to follow the original five DNA 
design principles specified in OC1. It also added two more. These principles would be 
continued throughout OC2. [Ref. 8:p. 16] 
a. Automate Map Graphics 

The objective of this design principle was to minimize the "culture shock" 
problem associated with new technology. Videodisc technology was to be used to store 
thousands of color photographs of standard military maps. The map images were to be 
overlayed with standard military symbols and displayed on a color monitor. This method 
would avoid the use of computer-generated maps which seemed less realistic and required 
extensive retraining (in the early 1980s). This technique had several secondary benefits: 



1 Interview between R. Laird, Lieutenant Colonel, USA, Defense Nuclear Agency 
Alexandria, Virginia and the author, 17-18 December 1987. 
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1 . Everyone would use the same maps 

2. Various combinations of friendly and enemy units could be displayed 

3 . The problem of working on map comers would be minimized 

All these C2 functions were carried out manually at the start of OC2. DNA 
believed that it would be impossible to operate efficiently in a DCP environment without 
automated map functions. [Ref. 8:pp. 19-20] 

b. Develop a User-friendly System 

Using familiar formats and simply operated equipment would ensure 
effective operation under high levels of stress. This design principle involved the 
application of the following concepts: 

1 . Programs would provide prompts to the operator on which steps to take to perform 
each function 

2. The automated map display would use images of standard army maps (stored on 
videodiscs) that presented an identical appearance to other maps in the command post 

3. The graphics backgrounds and message formats would be designed to look like the 
paper copies of messages already in use 

Users would not have to learn any new formats, and standard Army formats 
would be used as extensively as possible. [Ref. 8:p. 21] 

4. Exercise O bjectives during QC1 

The overall objective of Exercise REFORGER 82 was to conduct a limited test of 
the SPADS system that emphasized testing communications and components. The sub- 
objectives were to [Ref. 14:p. 1]: 

1 . Establish successful data transfer between V Corps and two 8ID elements 

2. Experiment with the use of three different types of modems to determine which 
could best support SPADS 

3 . Test the uninterruptable power supply (UPS) using field generator power at 8ID and 
German commercial power at V Corps main CP 

4. Conduct on-site training of V Corps and 8ID personnel 
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5 . Demonstrate the videodisc system of SPADS 

The overall objective of the next exercise, Able Archer 82, was to conduct a 
limited test of the SPADS system that emphasized two aspects: the testing of power, and 
the feasibility of a distributed data base system. The sub-objectives for the exercise were 
[Ref. 15:p. 1]: 

1 . Test the isolation transformers and the UPS in a field environment 

2. Continue training V Corps personnel on SPADS 

3 . Demonstrate videodisc and plotter capabilities 

The major objective during Wintex 83 was to test the capability of the SPADS 
prototype to provide information exchange and display capabilities in support of the DCP 
concept. The sub-objectives included field-testing of the recently deployed videodisc 
equipment and the new database management system (DBMS). [Ref. 16:p. 1-1] 

V Corps deliberately limited the SPADS test objectives during Exercise Caravan 
Guard IV in order to concentrate on the following sub-objectives that were deemed critical 
to the success of the V Corps DCP experiment [Ref. 17:p. II- 1 ] : 

1 . Establish and maintain a SPADS link with 8 ID 

2. Successfully transmit time-sensitive tactical information within V Corps and between 
V Corps and 8ID using EMS 

3. Integrate the new ACTO mini-SDSs into CBC operations 

4. Experiment with methods of updating the SPADS data base 

The 8ID also limited the objectives for this exercise to: 

1 . Demonstrate SPADS reliability by keeping all modules operational throughout the 
exercise 

2. Successfully transmit EMS messages among 8ID modules and with V Corps 

3 . Maintain the current battle data through Current Situation 

Table 10 presents an overview of the exercises and objectives for OC2 [Ref. 
8:pp. 28 - 301. 
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B . BOUNDING THE C2 SYSTEM 



This section uses the same approach as Chapter III. First, the workstation bounds of 
the hardware and software are described. Then, the module level describes the SPADS 
entities and structure within the confines of one modular command post. Finally, the 
network level defines the SPADS system within the procedural, geographical, and 
hierarchical bounds that interconnect the modules. 



TABLE 10 

OVERVIEW OF OPERATIONAL CAPABILITY 2 

Primary Objective(s) Date 

Exercise REFORGER 82 Sept. 1982 

• Interface V Corps-8ID 
•Improve communications gateway 

Exercise Able Archer 82 Nov. 1982 

•Field power system enhancements 
•Validate distributed data base 
•Deploy 8ID in vans 



Exercise WINTEX 83 March 1983 

•Disperse full corps command post 
•Field Automated replicated data base 
•Field video battlefield display system 



Exercise Caravan Guard IV May 1983 

♦Disperse and displace 8ID 

•Create V Corps-8ID command data base 



1 . Workstation Level Bounding 
a. Hardware 

The only new hardware introduced at the workstation level during OC2 
either involved enhancements to the SDS or supported a completely new function. The five 
peripheral devices added to the staff duty station were a local printer, a videodisc player, a 
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graphics overlay device, a joystick, and a graphics tablet. The local printer reduced the 
competition at the SOS. The videodisc player and graphics overlay device (both required 
by VBDS) were packaged in a rugged case that could be placed underneath the standard 
SDS to support the new automated map and overlay functions. The joystick allowed the 
SPADS operator to scroll and zoom the picture display, offering greater control the view of 
the battlefield within VBDS. The graphics tablet was useful both in preparing slides and in 
sketching plans or evaluations of the battlefield situation to be overlayed on the map 
display. [Ref. 17:pp. 36-40] 

The videodisc system was first demonstrated to V Corps and 8ID during 
Exercise REFORGER 82. Both headquarters considered it an important capability and 
expressed their desire to have it integrated into their SPADS modules [Ref. 13:p. 9]. The 
videodisc system was demonstrated a second time for acceptance testing during Exercise 
Able Archer 82. Again, V Corps and 8 ID were impressed by the C2 enhancements 
offered by these capabilities [Ref. 15:p. 8]. 

During the SID CPX in December 1982, there were a large number of 
hardware failures at the module, workstation and lower levels. A variety of the 
components needed to be repaired during this exercise (e.g., floppy disk drives, Apple 
microcomputers,circuit cards), and a large number of individual integrated circuit chips had 
to be replaced. They were destroyed by power surges, grounding problems, and 
unbalanced electrical loads on the SPADS equipment |Ref. 18:pp. 8-14], 

An obvious factor that contributed to an incomplete test of the DCP during 
OC2 concerned the capabilities of the 8-bit Apple II gateway configurations. There were 
many valid and invalid perceptions arising from use of these 8-bit gateways. The inherent 
limitations of the microprocessor, as well as the manner in which software had to be 
written for that system, required excessive "chaining" and "swapping" to access the many 
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SPADS programs and to pass files through the communications gateways. These two 
limitations made the system very slow, particularly when under heavy use. [Ref. 16:p. II- 
10 ] 

During Exercise Caravan Guard IV the long-awaited ACTO SDS was 
delivered. This configuration would soon be known as the mini-SDS. It became very 
popular with many SPADS operators and action officers, but it was particularly helpful in 
the cramped CPs at the division level. The ACTO SDS consisted only of an Apple 11+ 
microcomputer, two 5-1/4-inch floppy diskette drives, a thermal printer and a single B&G 
monitor in a small ruggedized container. | Ref. 17:p. 11-5] 
b. Software 

Software development during OC2 was divided between adding new 
functions for the SPADS user, or correcting or enhancing functions from OC1. The new 
functions were the Database Management System (DBMS) and the Video Battlefield 
Display System (VBDS). DBMS allowed the staff officer or user to maintain and 
manipulate data [Ref. 8:pp. 56, 60]. VBDS displayed an image of a standard military map 
with an overlay of both friendly and enemy unit locations, status, and other battlefield data 
[Ref. 8:p. 49]. One other function that was introduced was HPITS, which allowed direct 
access communications between two staff duty stations in different modules [Ref. 14:p. 6]. 

The two functions implemented during OC1, Current Situation and 
Electronic Mail System (EMS), were both substantially improved during OC2. Current 
Situation was able to access the local printer added to the SDSs, and the software was 
speeded up over several exercises |Ref. 1 7 : p . 1 1-5 1. Briefing, which provided the ability to 
create and present briefings to the Current Situation software, was also improved during 
this cycle [Ref. 17:p. II-6], The EMS code, improved during almost every exercise, 
allowed the operator to send or receive standard text messages, data, graphics and 
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computer code [Ref. 15:pp. 8-9]. Table 1 1 provides an overview of the OC2 software at 
the workstation level. 

V Corps had repeatedly expressed criticism for the commercial data base 
products delivered as stopgaps during OC1. Some of the G1/G4 functions could be 
handled by commercial spreadsheet products in Local Program Execution, but their usage 
was limited to worksheet-type formats and processing [Ref. 14:p. 9]. The new SPADS 
DBMS, using the commercial data base programming language PDBase, was fielded 
during Exercise Wintex 83. The DBMS incorporated both BIRS and OB formats for 
controlled input by the G3 Operations and G2 Intelligence respectively. Tables 12 and 13 
display the BIRS and OB input fields respectively. All other users could only read and get 
reports from the data; they did not have the capability to make changes to the data base. 
Table 14 shows the BIRS and OB report formats available to all users during OC2. The 
new VBDS function automatically extracted the current force data for overlay displays 
[Ref. 16:p. III-5]. 

The VBDS software displayed unit and battlefield data as a graphics overlay 
over a map image stored on a videodisc. VBDS took the data for graphics from VBDS 
files on the module's hard disk. These files contained information on unit location and 
status, control measures, and other battlefield characteristics required for a realistic 
automated map display. VBDS files were updated locally through the SDS with data 
received through the gateway from other modules. The graphics overlay was keyed to 
UTM 2 coordinates, and graphics were adjusted to reflect changes in scale or location. A 
graphics tablet was introduced for VBDS during OC2 to input additional overlay data such 
as phase lines or boundaries. (Ref. 8:p. 5 1 1 



2 Universal Transverse Mercator projection. 
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By Exercise VVintex 83. the VBDS code had been rewritten to use a new 
videodisc platter that contained expanded map coverage and photos. The new software 
added a PHOTO option on the menu: this option identified all locations for which photos 
were available on the map being viewed. Although the G3 did not have a need for this 
function, several other staff sections immediately requested information on the availability 
of photo images and their applications. IRef. 1 6: pp. III-7, III-8] 

2 . Module Level Bound inn 

The only change at the module level during OC2 was the introduction of a down- 
sized communications gateway station (CGS) for use in divisional command posts. This 
smaller model had a more limited capacity to support communications links, but was 



TABLE 11 

BOUNDING OC2 SOFTWARE 
AT THE WORKSTATION LEVEL 



Relational Data Base 

• PDBase (modified) 1 

• Enemy and friendly force structure 

Video Battlefield Display 

• Laser disks hold map images 

• Overlay text symbols 

• Accesses the two data bases 

Electronic Mail 

• Commercial package 

• Templates or free text 

• Standard communication procedures 



Briefing System 

• User-defined 

Graphic Editor 

• Two commercial packages 

• Rubber band drawing 

• Supports graphic tablet/joystick 

System 'fools 

• Word processing 

• Execute user software locally 

• Network manager 



3 PDBase is a registered trademark of 10TC, Inc. 
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TABLE 12 

BATTLEFIELD INFORMATION REPORTING SYSTEM 
(BIRS) INPUT FIELDS 



l:Unit 

2:Bde 3:Div 4:Type 

5:Ech 6:DDHHMM Z 7:Opcon 



8 :Enemy- Action 
9:Mission 



OPERATIONS STATUS 


lO:Mech 


1 1 :Ami 


12:Cav 


CofMass/FLOT 13: 








14: 


15: 


16: 




17: 


18: 


19: 





BATTLE RESOURCES 




Color Rating 


20: Tank/auth 




21:Tank/OH 


22:Tank 


23: HAW/auth 




24:HAW/OH 


25:HAW 


26: MAW/auth 


2 


7:MAW/OH 


28:MAW 






29:Personnel 








30:Tank ammo 








31:HAW ammo 








32:MAW ammo 








33:Diesel fuel 








34: Com mo 








35:Main-CP 








36:TAC-CP 








37:CDR's Overall 
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TABLE 13 



ORDER OF BATTLE (OB) INPUT FIELDS 
I :Report- number 

2:Unit-ID 3:Army 4:Div 5:Rgt 

6:Type 7:Size 8:Location 

9:Main-CP 10:Forward-CP 1 1:CE % 

12:Activity 

13:Cont'd 

14:Month 15:DDHHMM 



supported by more efficient code which allowed it to operate 25 percent faster than the 
original CGS. [Ref. 8:pp. 31-33] 

3 . Network Level Boundin'.? 

The only advancements at the network level during OC2 involved 
implementation of the system at wider or deeper levels. The Wintex 83 Exercise was 
extremely successful in demonstrating that the corps headquarters could operate effectively 
in the dispersed mode [Ref. 16:p. II-5]. No apparent degradation of C2 functions were 
experienced as a result of dispersing the CP modules over a large area during that exercise; 
however, the true potential of SPADS capabilities was not tested due to insufficient 
integration of support requirements in central C2 functions [Ref. 16:p. II-6]. 

The following exercise. Caravan Guard IV, simulated the dispersion requirement 
and merely used SPADS to pass all data from one module to another. Three corps modules 
(CBC, FSE and Plans) were co-Iocated in a civilian gymnasium complex while the Intel 
module was located nearby in command post vans. In contrast, SID spread its command 
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posts over a wide area, operating out of vans and tracked vehicles across the German 
countryside. The division main CP was approximately 40 kilometers from the corps main 
CP; DTAC was about 30 kilometers forward of the division main; meanwhile the division 
rear CP was located some 20 kilometers to the rear of the 8ID main CP. [Ref. 17:pp. 1-2, 
1-4] 

TABLE 14 

DATA BASE REPORTS AVAILABLE DURING OC2 

BIRS REPORTS 

Provides the composition of each unit sorted by OPCON 

Provides the color codes for current status of equipment 

Prints detailed equipment status to SOS only 

Prints the Front Line of Troops report and Task 
Organization information to the SOS only 

Provides the UTM coordinates of friendly locations 

Provides the friendly unit missions sorted by OPCON 

Provides a description of enemy activity in friendly 
sector 

Prints a copy of each report to the local printer only 
OB REPORTS 

Provides a history of a particular unit over time. 
(Requester must know the unit's name in advance) 

2. Listing of Reports by Time Provides a listing of Intelligence reports sorted by date 

3 . Combat Activity Provides the combat activities of all units or a particular 

unit. Report is sent to the SOS only 



1 . Unit Composition 

2. Equipment Status 

3 . Detailed Equipment 

4. FLOTandTASKORG 

5 . Locations 

6. Missions 

7 . Activity of Enemy 

8 . Print All Repons 

1 . Unit Location History 
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C. C2 SYSTEM ARCHITECTURE 
1 . Workstation Level I n te<? rn t ion 

Throughout OC2, software and hardware changes produced new opportunities 
for the staff sections to interact with SPADS. Although only two new software packages 
were introduced, they generated more interest from the operationally oriented staff elements 
than any of the previous developments. 

The next two figures present the integration of the two new software functions 
with the C2 system and the C2 process. Figure 4.2 displays the integration of system, 
process and function with the Database Management System [Ref. 8:pp. 58-60]. Figure 
4.3 shows the integration of entities, structure and functions with the Video Battlefield 
Display System software [Ref. 8:pp. 53-55]. 

2 . Module Level Integration 

The addition of SPADS hardware and software slowly influenced the structure, 
organization, procedures and information flow patterns of the V Corps and 8ID command 
posts. In OC2 it gradually became clear that without expressed command interest in this 
experiment, only certain staff sections or elements would voluntarily take up SPADS as an 
effective C2 toolset; most staff sections just ignored SPADS during the exercises. The 
G3 — the proponent of operations, plans and training — would have been the logical driving 
force behind a system that could restore effectiveness to the dispersed CP configuration. 
That was not the case, however. Only two modules — Fire Support and Plans — took full 
advantage of SPADS. 
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Figure 4.2. Integration of Data Base Management System 
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Figure 4.3. Integration of Video Battlefield Display System 



a. Fire Support 



The V Corps Artillery leadership, from the commander and the Assistant 
FSCOORD down to the FSE staff and NCOs, demanded that SPADS meet their needs for 
targeting and fire support management. Those leaders invested in SPADS by making 
valuable personnel available for training and then assigning them to primary SPADS duties 
during all exercises. The FSE module achieved SPADS self-sufficiency before any other 
modules. The FSE staff developed its own procedures for integrating SPADS operations 
into primary functions before any exercises and tested them throughout OC2. At FSE's 
initiative, FSE and Intel modules established their own network and procedures for using 
SPADS to improve the processing and passing of critical targeting data for the deep attack 
[Ref. 16:pp. 11-15 -11-16]. The TCATA evaluation during Exercise Wintex 83 found that 
the FSE's procedures worked extremely well [Ref. 16:pp. 11-22 - 11-25]. 
b. Plans 

The G3 Plans and Exercise officer selected a highly talented and aggressive 
NCO at the beginning of OC1, sent him to all of SPADS training, and assigned him as the 
module system manager. The G3 Plans came to expect the system to speed up and smooth 
all of the internal operations of the module. All Plans action officers soon became adept at 
using the system to produce and transmit OPLANS during exercises. In Exercise Wintex 
83, the Plans module transmitted ten OPLANS and seven changes; this represented a 400 
percent increase over previous exercise results. The Plans module had the highest system 
usage per individual during Exercise Wintex 83. [Ref. 16:p. 11-17] 

3 . Network Level Architecture 

There are two perspectives in examining the network level architecture during 
OC2: connectivity and procedures. Communications were finally starting to support 
SPADS by the end of OC2. In addition, numerous novel connections were made to the 
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gateways during this cycle. On the other hand, integrating the expanding network 
architecture into the organization and procedures of the corps or division had been a 
complete failure. This section examines these two aspects of the network level. Once the 
corps was able to support the DCP concept through SPADS communication gateway 
stations, it was in a position to begin integrating the V Corps C2 process from individual 
staff duty stations throughout the entire network, 
a. SPADS Connectivity 

Individuals continued to achieve resourceful solutions to communications 
problems throughout OC2. During REFORGER 82, soldiers from the 8ID decided to 
connect the 8 ID TAC CP gateway to another gateway some 180 feet away using WD-1 
field wire. This experiment worked so well that they used that connection for the 
remainder of the exercise. [Ref. 14:p. 8] 

The V Corps Commander requested that the V Corps main CP SPADS 
gateway connect to a VII Corps pre-production model AN/UYQ-30, Tactical Computer 
Terminal (TCT). One staff duty station was hardwired to the TCT using a military version 
of an RS-232 interface. Not only were the two systems physically linkable, but they could 
transfer files between them. DNA observed this pairing as a possible candidate for future 
interoperability funding. A successful project along these lines would have given the V 
Corps automated C2 system a means to communicate with the VII Corps militarized, 
automated C2 system. [Ref. 14:p. 9] 

By exercise Caravan Guard IV, V Corps had learned how to effectively use 
the corps multichannel system to support the SPADS network. The Corps C-E section had 
begun to understand how to accommodate SPADS requirements, and the After Action 
Report indicated that the corps could make further progress in the future. [Ref. 17:p. II- 
13] 
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b. Procedures 



At the start of OC2 there were no SOPs — at any echelon — for the 
employment of SPADS. By Able Archer 82, V Corps had begun to make limited progress 
towards identifying the information necessary to develop a SPADS SOP. There was no 
8ID document related to the preparation or deployment of SPADS [Ref. 15:pp. 7, 10]. A 
new set of SPADS manuals were delivered to V Corps in January 1983. The Operator and 
System Manager Manuals were distributed immediately, and SPADS operators took these 
manuals to the field during the last two exercises. The Staff Officers’ Manual, however, 
was not even read by those officers with primary S^ADS responsibilities. Even though 
guidelines for an extensive SPADS SOP were contained in the manual, no SOPs were 
developed by any staff section after this information was distributed. By Caravan Guard 
IV only a Current Situation SOP had been developed by any staff section within V Corps. 
[Ref. 17:p. HI- 12] 

Two of the primary lessons V Corps learned after the series of exercises that 
culminated in Wintex 83 were that: (1) evolutionary development must be based upon user 
identification of needs, and (2) system capabilities must be designed and/or enhanced in 
accordance with deliberate plans to integrate SPADS into the V Corps C2 processes. 
Unfortunately, throughout OC1 and 2 there had been no systematic approach to defining 
and testing user applications or in integrating them into command post routines [Ref. 
16:pp. 11-26, 11-27], The TCATA evaluation of SPADS during Wintex 83 should have 
forced the commander and the staff to recognize their situation. The outbrief was honest 
and to the point: V Corps either had to embrace SPADS and internalize it within the corps 
C2 system, or it had to abandon it entirely. [Ref. 16:pp. 11-27, 11-28] 
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c. Inhibiting Factors 

The two principal factors inhibiting the progress of SPADS throughout the 
first two OCs were: (1) insufficient primary staff emphasis, and (2) insufficient integration 
of SPADS into the V Corps C2 processes [Ref. 16:pp. II-8 - II- 10]. 

V Corps had not placed sufficient emphasis on educating primary staff 
officers on the value a distributed data base had in meeting their needs. The DCP concept 
represented a dramatic change in traditional C2 procedures. These applications were seen 
as foreign to tactical operations by many senior officers [Ref. 12:pp. 21-22]. Many senior 
officers conceded that these methods might have value; some even gave them verbal 
support. But almost uniformly throughout the V Corps CP, their subordinates were 
isolated from the staff duty stations and SPADS products during exercises [Ref. 16:p. II- 
8 ]. 

Conceptually, the SPADS distributed and replicated data base could have 
provided the V Corps commander with the critical common perception of the battle and 
with specific information required for timely decision making. Unfortunately, most of the 
primary staff had not devoted any time to learning SPADS, nor had they directed their 
overburdened subordinates to use or learn SPADS. As a result, most staff sections could 
not identify information flows that would satisfy their own C2 functions by the end of 
OC2. [Ref. 16:pp. II-8 - II-9] 

d. Contributing Factors 

Exercise Caravan Guard IV demonstrated to V Corps and 8ID commanders 
that SPADS could have been a reliable tactical C2 system during the DCP experiment if 
they had devoted resources to proper planning and operational procedures. They 
considered the overwhelming success of these exercises as the first step in a new phase of 
SPADS development. At the post exercise In-Progress Review, V Corps adopted a draft 
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SPADS charter (displayed in Table 15) and adopted a tentative plan for a new 
organizational element for controlling SPADS within V Corps. [Ref. 17:pp. 11-14 - 11-16] 

TABLE 15 

V CORPS SPADS CHARTER 

• Develop a DCP program plan with specific exercise objectives 

• Identify and prioritize information needs to support procedures and decision making 

• Define how SPADS works in each module 

• Develop a SPADS program plan with specific exercise objectives, training 
requirements and organizational responsibilities 

• Develop SOPs for DCP and SPADS 

• Conduct mini-CPXs in garrison prior to each exercise 

D. DATA GENERATION 

The data generated for this OC are shown in Table 16. 3 The data generation 
worksheet and formulas discussed in Chapter II were used to produce values for this OC. 
The means for each evaluation category are displayed in Figure 4.4. The next paragraph 
briefly discusses the data generation procedures presented in Chapter II. 



4 The following sources provided raw data on OC2 exercises: Ref. 13 (REFORGER 
82), Ref. 14 (Able Archer 82), Ref. 15 (Wintex 83), Ref. 16 (Caravan Guard IV), Ref. 17 
(8ID CPX). 
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Figure 4.4. Means for Each Category During OC2 



To begin the data generation for this operational capability, after action and lessons 
learned reports were collected for each exercise from V Corps, DNA, and the developer. 
Using the worksheet, definitions, and procedures specified in Chapter II, values were 
determined for every measure from each exercise. The measures were individually 
considered as binary conditions for each DCP module that participated in the exercise being 
evaluated. The summed measures (e.g., FAIR, XMOTi, and XCSTi) received their 
cumulative, unweighted scores based upon their constituent measures of performance or 
effectiveness. The final measure, C2/FE, was calculated using the procedure specified in 
Chapter II. The results for each exercise are displayed in Table 16, and the means for each 
evaluation category are shown in Figure 4.4. 

E. AGGREGATION AND INTERPRETATION OF MEASURES 

The extensive information available in these After Action and Lessons Learned Reports 
(Ref. 14 - 18) contained a great deal of data and were extremely helpful in understanding 
the characteristics of the experiments during the exercises. 

1 . C2 Mission Orientation 

The value of C2 Mission Orientation, XMOTi, seems to start at approximately 
the same level as OC1, drops sharply and then rises dramatically at the end of OC2. There 
is a measurable gain in effectiveness by the end of the experiment period; however, there 
was a tremendous loss of functionality during the period of REFORGER 82 through the 
8ID CPX in December 1982. The following three sections interpret the three components 
of C2 Mission Orientation. 

a. C2 Process 

There was a dramatic loss in functionality from the end of OC1, in June 
1982, through the 8ID CPX that December 1982. While the functions of the V Corps 
commander and staff may have remained constant, the DCP environment and SPADS, in 
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particular, caused a severe decrease in the commander's and staffs abilities to exercise 
command and control of the corps. Only the sharp rise in FAIR values during the last two 
exercises represents the increasing functionality of the SPADS system within the DCP 
environment. 

b. Physical Entities 

Physical entities continued to change during OC2. Some new software was 
introduced, established software functions were constantly refined, and new hardware was 
integrated into the DCP environment. The value of capacity does not remain constant for 
e:< :h module that was already in the V Corps DCP. As the modules were rearranged from 
exercise to exercise, the system's capacity diminishes until the exercises in spring 1983. 
Then, the total aggregated value increases as the modules were networked by the 
communications gateway stations to one another through TASS. 

c . Structural Components 

The value of the structural measure rises slightly, decreases again, and 
finally steadies at the end of OC2. For the first time, SPADS was able to accomplish the 
transmission of critical information required by the commander. Despite peak transmission 
periods and temporary communications outages during each exercise, SPADS was finally 
able to provide the V Corps commander with dependable, critical, decision making 
information. 

2 . Command Survivability 

SPADS continued to make significant gains towards achieving command 
survivability during OC2. Except for the initial three command post exercises, dispersion 
between modules gradually increased and more modules were added to the corps system. 
Continuing the trend from OC1, no progress was made toward redundancy; this continued 
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to be specifically related to command influence and staff interest. Finally, the values of 
reliability and transportability remain constant for each module during OC2. 

3 . C2 Force Effectiveness 

SPADS did evolve during the operational capability based upon the operational 
lessons learned. It was still not clear how much progress SPADS had made during this 
19-month period. The evolution involved hardware, software, protocols and 
communications interfaces. SPADS only began to affect the organization, procedures or 
concept of operations for the V Corps command posts at the end of OC2, during the 
Caravan Guard IV In-Progress Review [Ref. 17:pp. 11-14 - 11-16]. The values of C2/FE 
rise distinctly at the end of the experiment period when the V Corps and 8ID scaled 
objectives down to realistic levels and sought to gain maximum advantage from their 
automated C2 system. The values of all significant measures, i.e. XMOTi, XCSTi and 
C2/FE, nearly double in value by the end of OC2. 

Figure 4.5 provides the cumulative (unweighted) value of each evaluation 
category for each exercise of OC2. Figure 4.6 displays the changing value of each 
measure — XMOTi, XCSTi, C2/FE — throughout each exercise of the second operational 
capability. 

F. SUMMARY 

The second operational capability was a turbulent period for V Corps, 8ID and DNA. 
All of these organizations had specific objectives for this period, and all of their objectives 
failed to some degree. This section frankly discusses procedures, training, 
communications, hardware and software as they relate to the performance of the V Corps 
and 8ID DCP experiments. 
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Figure 4.5. Evaluations of the Three Problems for OC2 
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Figure 4.6. Comparisons of the Three Measures for OC2 




The lessons learned from the SPADS evolutionary development cycle must focus on 
procedures and training because these two structural components are critical to the success, 
or lack thereof, of a prototype C2 system. To a large extent they determine the 
effectiveness of the fielding and implementation. System designers should have been more 
careful planners, thoughtful schedulers and more cognizant of requirements, committed to 
successful implementation, and engaged in a systematic training program if they wanted to 
insure SPADS user effectiveness. This does not imply that system and personnel 
problems, diagnoses, fixes and modifications that resulted as a response to system 
problems would not ha’'e occurred. These situations are a necessary part of any rapidly 
fielded system. The lessons learned by users in the field environment are the basis for 
system improvement and enhancement in an evolutionary development cycle. The scope 
and speed of the system's advancement, measured objectively, was significantly influenced 
by staff priorities for the system, SOP construction and revision, and the staffs attitude 
toward effective training and retraining. [Ref. 8:p. 65] 

1. Procedures 

Throughout the evolutionary development cycle, there was evidence that a highly 
reliable tactical command and control could only be implemented if adequate planning and 
operational procedures were employed. A critical factor in the success of this evolutionary 
development program was the careful definition of minimum essential information and the 
data distribution architectures by the headquarters staffs. This essential step was almost 
totally lacking throughout the first two operational capability cycles. [Ref. 8:p. 65] 

Emphasis should have been placed upon soliciting and coordinating staff 
requirements of the corps and division headquarters. These staffs significantly failed to 
produce a working SOP that reflected the flow, storage and retrieval of messages, data ,or 
briefings from SPADS. Without this document, staff requirements could not be translated 
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into data to support the distributed C2 system. Also lacking was a listing of the operator 
and staff officer responsibilities for information processing procedures. The SOP should 
have indicated who, what, when, where and how each test of the DCP program related to 
the functions that were being supported by the staffs. Little time was available for this 
critical document, and there is no evidence that any was expended to accomplish this task. 
Its completion during OC2 would have greatly enhanced the quality of implementation and 
the rapid fielding of the distributed C2 system. [Ref. 8:p. 69] 

2 . Training 

The headquarters' staffs should have carefully scrutinized the personnel selected 
for training. They did not ensure that potential operators and system managers had 
sufficient time to gain experience with SPADS. Experienced SPADS users could have 
clearly identified those procedures that could have been better automated, pinpointed 
obsolete functions or equipment, and identified the manner in which new operational 
procedures could have been implemented. The corps would have obtained an ongoing 
program that produced quality operators and system managers who could have significantly 
contributed to fine tuning SPADS to meet the Army's needs. [Ref. 8:p. 67] 

Two other integral training program components were lacking. On-the-job 
training and pre-exercise rehearsals were equally necessary for users to understand the 
enemy threat, the constraints of the exercise scenarios, and the functions of SPADS in the 
DCP environment. 

Training documentation should have reflected the level of sophistication of the 
commercial technology and should have been incorporated into SPADS itself. Self-paced 
documentation could have been available for the user who recently joined the organization 
or who missed the formal training cycle. On-line tutorials using SPADS videodisc 
technology could have been substituted for the lengthy manuals to assist the operator in 
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learning ho'v to set up and operate the staff duty stations. A critical oversight was the lack 
of a small, weatherproof, pocket-sized reference manual that could be carried by the 
operator or permanently affixed to the SDS; this would have been superior to the bulky 
system documentation that was nearly always damaged or left behind by staff officers and 
users. [Ref. 8:p. 67] 

Finally, data file development for future exercises should have been initiated as 
soon as possible within the guidelines of the requirements document and completed before 
the anticipated move to field locations. Selected operator refresher training could have been 
conducted concurrently with this development. Following the move to the field, 
immediately after system equipment and communications were installed and operational, 
testing and demonstration of the system should have begun. These tests and 
demonstrations should have included mini-exercise, requirements-driven scenarios to 
insure a comprehensive shakedown of SPADS prior to commencement of the exercise. 
[Ref. 8:p. 69] 

3. Communications 

Both the V Corps Signal Brigade's and Communications-electronics (C-E) staff 
section's lack of involvement with SPADS during the first two OCs severely affected its 
development. Their early involvement was absolutely necessary for an initial good start as 
well as to planned progress during the following evolutionary development cycle. As 
military technical consultants to the system, they possessed the ability to determine whether 
the system could actually meet the operational needs of the V Corps DCP concept. These 
communications experts would have been an excellent source of advice in the planning of 
exercises, and could have insured that operational staff sections conformed to the new 
automated procedures. [Ref. 8:pp. 74-75 1 
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Instead, serious interoperability problems caused major time delays and 
adversely affected the goals and purposes of numerous exercises and tests. The C-E staffs 
involvement would have insured that essential time was devoted to testing the system, 
observing the man-machine interface, obtaining user feedback, evaluating system usability 
and meeting the requirements of the OC. Moreover, these communications experts could 
have predicted avoidable problems that seriously frustrated new operators and system 
managers who were often uncomfortable in their roles, and could have contributed to the 
success of many DCP exercises. [Ref. 8:p. 74] 

Another area where expert help was needed was in the communications method 
used to connect local modules to one another and to other modules at longer distances. 
Operational users failed to learn a basic lesson: before deploying to the field, users need to 
devote considerable time to planning and pre-exercise engineering in order to ensure a 
sufficiently good system interface and a better chance of success for communicating 
between microcomputer based systems. The C-E staff was already planning and 
engineering tactical multichannel systems, and they should have assimilated SPADS into 
their area of responsibility. [Ref. 8:p. 74] 

Regardless of the technological advances or the sophistication of the system 
enhancements, SPADS could not meet its stated objectives unless the communications 
problems — especially with the interface — were remedied. Experienced communications 
planners were needed to make provisions for the distribution of information among 
echelons vertically as well as horizontally across staff support functions. The V Corps 
Signal community's lack of involvement prevented reliable and reasonable communications 
capabilities from being planned for and employed during the first two operational capability 
cycles. The most significant problem in communications was not with the communicators 
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(who ignored SPADS), but with the lack of command influence which should have insured 
that professional communicators were involved in SPADS from the outset. [Ref. 8:p. 75] 



4 . Hardware 

The hardware lessons learned during OC2 interact with the lessons learned in 
preceding summaries. The relatively minor hardware problems which developed during 
the first two OCs indicated that the evolutionary development cycle is a good means to fine 
tune hardware components that have to be fielded quickly. The successes of the SPADS 
system hardware in meeting and exceeding user requirements resulted from an early 
fielding strategy and hands-on use that supported the effectiveness of the evolutionary 
development concept. [Ref. 8:p. 83] 

It may seem obvious that hardware had to be integrated with software into a 
usable system that automated the V Corps operational procedures to benefit the DCP. 
However, the field users, DNA, and the developer had to develop a three-way dialogue 
before they could produce and field a C2 system that permitted the staff to operate more 
efficiently and allowed the commander to control his forces effectively. The hardware had 
to possess the capabilities required to support the system software. Moreover, the software 
had to be tailored to meet limitations of the hardware that were first identified during field 
tests and exercises. Only in this manner could the users distinguish between hardware and 
software problems in the SPADS system. [Ref. 8:p. 82] 

Hardware that was difficult for the average military user to operate and maintain 
would be abandoned as inoperable during high stress periods — when it was most needed to 
contribute to a survivable system. The proponent of the system and the developer should 
have actively obtained feedback about the system hardware. Staff officers, who depended 
upon SPADS information processing and decision support capabilities, could have been 
among the best reviewers of hardware failures and inadequacies. Moreover, senior staff 
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officers were in a unique position to judge how the staff adjusted operational procedures to 
the constraints imposed by the system hardware. Likewise, the advice of SPADS 
operators would have been valuable because they were closest to the hardware problems 
and were the most likely to make worthwhile judgments regarding its usability. [Ref. 8:pp. 
82-83] 

5 . Software 

The interaction effects among the other system components (procedures, 
training, communications, hardware and user inexperience) adversely affected the 
capability of SPADS software to adequately perform its intended functions. Software 
development should have taken these constraints of the users' environment into 
consideration. A positive example of such an adaptation was how the developer, after 
gaining an understanding of military communications traffic loads on TASS, developed 
software that only transmitted the data that were absolutely essential. It was not necessary 
to transmit entire files. Other successful examples include message formats being stored on 
every module's hard disk and all maps being stored on videodisc. Once again, only the 
new data required to fill in reports or to show unit locations on map overlays had to be 
transmitted and received. [Ref. 8:pp. 87-88] 

During the first OC, there were many instances where usability, storage, update 
or retrieval interfered with SPADS effectiveness. Throughout the second OC the developer 
made a concerted effort to minimize those software deficiencies that adversely affected 
operations. However, the initial fielding and testing of software was absolutely essential in 
order to identify those shortcomings that could be diagnosed and corrected before the 
following exercises and test. [Ref. 8:p. 86] 

The majority of the software problems that occurred during the second 
operational capability related to the following tasks [Ref. 8:p. 85]: 
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1 . Tailoring software to meet operational user requirements or automation needs 

2. Increasing software speed and efficiency 

3. Fine tuning system software to make it more usable and responsive to staff officers' 
needs 

4. Eliminating system software bugs that impede the execution of system utilities 

5. Advancing the software's technological capabilities to perform more sophisticated 
staff operations 

6. Integrating existing and new software with hardware enhancements that develop as 
the system matures or the staff functions change 

Although much of the responsibility for software remained with the developer, 
staff off ec- ; should have ascertained which operational functions and procedures required 
automation early in OC1. These officers should have developed SOP documentation that 
clearly addressed those considerations so that hardware meeting those software 
requirements could have been carefully selected and developed. And they should have 
identified appropriate data structures to support the software development. The developer 
could not foresee future changes of the system, so staff officers should have concisely 
specified the procedures and functions that would benefit most from software development. 
[Ref. 8:p. 87] 

6 . Outlook 

This chapter's summary catalogued the myriad sources of problems that afflicted 
the SPADS experiment throughout OC2. In spite of these observations, it was clear that 
DNA saw SPADS as continuing to make significant progress towards the fully dispersed 
command post concept for both the corps and the division. Capabilities demonstrated in 
the exercises during 1982 and 1983 verified the viability of the DCP concept in employing 
a prototypical dispersed C2 system linked through standard tactical communications. By 
the end of OC2, many necessary improvements to fully implement the DCP concept and 
fully support SPADS had been identified. Therefore, DNA decided to continue the 
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experiment through the end of Fiscal Year 1985 to fully demonstrate the concept and to 
identify and improve the methodology by which it could be fully implemented. 
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V. OPERATIONAL CAPABILITY 3 



A. PROBLEM DEFINITION 

Funding for the third operational capability started in July 1983 and field-testing began 
in September during REFORGER 83. OC3 was planned and designed to start with the 
first two operational capabilities as a baseline condition and progress from there. Once 
again, designs and capabilities were tested and refined during the OC's five exercises: 
REFORGER 83, Able Archer 83, Crested Eagle 84, Caravan Guard V, and RF.FORGER 
84. The Army conducted an external evaluation of SPADS during Wintex 85; this one 
exercise is also considered part of the evaluation. 

This section addresses four issues central to problem formulation: 

1 . What were the stated requirements of OC3? 

2. What tasks from the statement of work (SOW) supported OC3? 

3 . What other design principles, mandated by DNA, guided the development? 

4. What were the goals of each exercise? 

Figure 5.1 shows the eight requirements of OC3 along a month by month timeline. 
The dates of the five exercises during OC3 are marked by below the central rectangle. 
The objectives of OC3, based upon requirements and technological characteristics, are 
shown to the right. 

1 . Requirements for OC3 

The eight OC3 objectives to be completed during the final 20-month period of the DCP 
experiment were to: (1) develop a mini-staff duty station for G3 ACTOs and divisional use, 
(2) modify equipment for use in vehicles, (3) develop interface requirements for other C2 
systems, (4) develop interactive graphics, (5) refine/enhance the database 
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Figure 5.1. Overview of Operational Capability 3 



management system, (6) field a 16-bit communications gateway station, (7) prepare V 
Corps for self-sufficiency, and (8) complete the V Corps DCP concept. 

a. Develop a Mini-Staff Duty Station for G3 ACTOs 
and Divisional Use 

Four ACTO SDSs were demonstrated for acceptance testing during OC2. 
Based on overwhelming staff action officer acceptance, DNA decided that all non-VBDS 
staff duty stations for the 8ID should be converted to the mini-SDS. In addition, once the 
new 16-bit gateways were fielded, the older Apple gateways would be converted into mini- 
SDSs for distribution to other units. [R^f. 17:p. II-5] 

b. Modify Equipment for Use in Vehicles 

The 8ID experienced recurring hardware, grounding, and power problems 
throughout OC2. During Exercise REFORGER 82, 8ID tested UPSs with field generators 
and German commercial power to determine whether these devices could protect SPADS 
equipment. [Ref. 14:pp. 1-6] During the 8ID CPX in December 1982, there were a large 
number of failures on the local area network, within the SDSs and at the gateways. 
Numerous interface cards and integrated circuit chips were destroyed by power surges, 
grounding problems, and unbalanced electrical loads. [Ref. 18:pp. 8-14] 

DNA specified that hardware solutions would be implemented to protect the 
8ID SPADS equipment when it was operating in the M-4 vans. 

c . Develop Interface Requirements for Other C2 Systems 

The successes during past exercises produced the requirement for 
interconnectivity with other Army C2 systems [Ref. 14:p. 9] The requirements for OC3 
were to develop rigorous interface specifications or protocols for: (1) MICROFIX, (2) the 
Tactical Computer Terminal (TCT), (3) TACFIRE and (4) the Target Analysis and 
Planning (TAP) program. [Ref. 8:pp. 33-35] 
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d. Develop Interactive Graphics 

During past operational capability cycles there had been limited success with 
the timely production of manually generated decision graphics. This shortfall would be the 
impetus for a software effort that integrated information from SPADS DBMS and Briefing 
to produce an automatically updating decision graphic for Current Situation. 

e. Refine or Enhance the Database Management System 

V Corps G3 Operations and several other staff sections had expressed a 
need for data bases with additional functions. The G3 had also requested that instructions 
be given to key V Corps staff personnel on the construction of data bases using SPADS 
DBMS. [Ref. 16:p. III-6] 

During Caravan Guard IV staff users suggested that more rapid data base 
updates could be accomplished in future exercises if the data bases were updated directly, 
rather than through information passed by electronic mail [Ref. 17:p. 1-4]. 

These two user requirements would be implemented during OC3. 

f. Deploy a 16-bit Communications Gateway Station 

The original 8-bit gateway could not meet the needs of the V Corps DCP by 
the end of OC2. Task 1 1 of the SOW required the developer to convert the 8-bit gateway 
code to the 16-bit microcomputer selected for the new gateway. New CGSs were needed 
to increase the speed of message traffic transmission and reception, to reduce LAN and 
hard disk contention, and to produce more efficient management of the module's computer 
resources. [Ref. 8:p. 33] 

g. Prepare V Corps for a Successful Transition to 

Self-sufficiency 

DNA selected V Corps to be the testbed for the DCP experiment in 1981. 
The agency had provided all guidance and logistics, as well as most of the funding, 
through the end of OC2. One of the conclusions of the Caravan Guard In-progress Review 



103 



(IPR) was that V Corps should develop a plan to manage SPADS as an Army C2 program. 
The V Corps Charter, presented in Chapter IV, would be the starting point for the transition 
to self-sufficiency. [Ref. 17:pp. 11-14 - 11-16] 

h . Complete the V Corps DCP Concept 

The completed V Corps DCP concept would consist of: (1) horizontal 
command and information flow throughout the dispersed corps modules, and (2) vertical 
command and information flow from the corps commander to his immediate subordinate 
combat commanders in the 3AD, 8ID, 1 1ACR, and 12CAG. 

2 . Tasks from the Statement of Work 

a. Task 15: Provide Extended Exercise Support 

Test objectives and key data elements needed for the evaluation of V Corps 
DCP exercises were to be identified for each CPX, FTX, etc. so that systems evaluators 
from supporting Army agencies could monitor the progress of SPADS during OC3. 

b. Task 16: Provide Continued Hardware and Software 

Development for the DCP Program 

The developer was to accomplish two tasks: (1) refine or correct software 
problems identified in past exercises, and (2) continue 16-bit microprocessor CGS 
development. 

c. Task 17: Provide Exercise Support 

In July 1983 TRADOC provided $1.4 million to provide support to the V 
Corps and 8ID DCP programs through the second quarter of fiscal year 84 (FY 84). The 
Army Command and Control Initiative Program (TACIP) was to monitor the 
accomplishment of this task. 1 



interview between R. Laird, Lieutenant Colonel, USA, Defense Nuclear Agency, 
Alexandria, Virginia and author, 17-18 December 1987. 
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d. Task 18: Software Support 

The developer was tasked to: (1) continue development of the 16-bit 
communications gateway, (2) continue user identification requirements, and (3) customize 
software for division usage. 

e. Task 19: On-site Support for the DCP Program 

This task required the developer to establish an on-site support facility at V 
Corps Headquarters in Frankfurt, West Germany. The facility would be completely 
furnished with tools, documentation, and spare parts and be supported by an integrated 
logistics support plan. Two full-time employees, a software developer and a systems 
integrater, were to provide on-site support 40 hours per week in garrison and as required 
during exercises. [Ref. 8:p. 20] 

f. Task 20: Continued Support 

The first part of this task would provide software support and corrections 
during exercises. It would also improve the SPADS database management system and 
integrate the DBMS with automatic graphics output. It would investigate the display of 
improved decision graphics information and require that the SPADS communication 
software be modified to implement both TCT and MICROFIX protocols. 

g. Task 21: Field a 16-bit Communication Gateway Station 

The developer was required to accomplish the following at V Corps: (1) 
field a 16-bit microcomputer-based CGS, (2) install the 16-bit CGS, and (3) conduct 
training for the new gateway. 

h. Task 22: Transition Training and Support 

This final task of OC3 was supposed to assist V Corps and 8ID SPADS 
users in preparing to be self-sufficient after FY 84. The developer was required to: (1) 
conduct pre-exercise support and evaluation and assist commander and staffs in identifying 
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SPADS objectives and performance standards based upon such objectives; (2) conduct 
technical support for Caravan Guard V and REFORGER 84; (3) publish post-exercise 
reports; (4) conduct an expanded training program at V Corps; and (5) update all 
documentation, revise the User's Manual, and produce a free-standing reference flip card 
set. 



TRADOC provided $350,000 for this task in February 1984; the first 
$190,000 was to be used by 30 September 1984 and the final $160,000 used by 30 
September 1985. 2 

3 . SID REFORGER 84 Statement of Work 

The 8ID developed a separate statement of work to support the plans that they 
had developed for REFORGER 84 [Ref. 20:pp. 1-2]. (These plans are discussed in detail 
later in this chapter.) 

a. Task 1: Develop a Hardwire Interface Between a SPADS 
Workstation and a TACF1RE System 

This task required that a MILSTD 188 interface to TACFIRE be developed. This 
interface had to be capable of transferring data files between the TACFIRE and SPADS 
systems as well as passing free text from SPADS to TACFIRE. 

b. Task 2; Develop a System for Automatically Updating SPADS 
Position Location Data Bases Based Upon Electronic 
Information Provided by TACFIRE 

The developer was required to develop a system to receive and interpret the 
data base information coming from TACFIRE through the hardwire interface. The SPADS 
system was required to insert this data into a PDBase relation within the DBMS. 



2 Ibid. 
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